6 ms·

I2P-Bote – Email plugin for the I2P network that uses a distributed hash table

74 points by jerheinze 9y ago

mintplant 9y ago
I'm always wary of this "publish to everyone, encrypted for the recipient" model (Bitmessage, I2P-Bote, etc) because if somewhere down the line a flaw in the crypto is discovered, that's your entire message history irrevocably exposed to the world.
- atemerev 9y ago
  If the flaw in the crypto of such magnitude is discovered, the exposure of your message history will be the least of your problems.
  - mintplant 9y ago
    That doesn't really do anything to assuage my concern. Crypto bugs are discovered in software all the time.
    - problems 9y ago
      You're right, crypto bugs are discovered in software all the time. However, many of these bugs rely on highly active attacks, oracles, etc. Very few allow offline decryption, For that you'd have to do something incredibly stupid and easy to catch like reuse the same key and IV for multiple messages. Higher level cryptography libraries like nacl prevent these concerns almost entirely.
    - atemerev 9y ago
      Bitcoin core is self-contained crypto bug bounty program :) Rewards are enormous.
  - drzaiusapelord 9y ago
    Not really. Not all crypto failures are the math failing or quantum computers suddenly becoming cheap and effective. Its usually just a bad implementation of a solid concept. The bad implementation allows for some side-channel attack and off you go.
- niftich 9y ago
  Is your concern the same whether a single static key used for the entire message vs. a cryptosystem that offers forward secrecy; or solely based around the idea that having the (encrypted) content publicly disseminated in the first place is an unacceptable risk that enables offline cryptanalysis and, in the case of a very patient attacker, data hoarding? Is your threat model different from, say, a state-level MitM, who today can record IP traffic that happens to include TLS and simply wait the equivalently long time until the underlying ciphers are broken and obsolete? Is the information being exchanged of such sensitivity to require outlasting a typical human lifespan, making the possibility of offline cryptanalysis, enabled by the dissemination of still-encrypted content, an unacceptable risk? If the cryptosystems themselves have comparable properties, do ancillary factors make, say, the I2P DHT usecase worse than the TLS-over-the-public-web usecase, given that a darknet overlay network typically has a self-selecting clientele vs. the vast numbers of people defaultly using TLS, making publicly accessible but encrypted blobs traversing the former more tempting targets in a smaller haystack?
  - Klathmon 9y ago
    I can't speak for the parent commenter, but just about every cryptosystem created has made the claim that the data secured will be secure for "longer than a typical human lifespan", and yet time and time again that is shown to be false. Attacks are found, cryptosystems are broken, key strengths weakened, side channel attacks created, computers get faster, dedicated hardware is created, etc... Pretending that we got it 100% right this time seems naive at best, and adding a small amount of "defense in depth" by not giving everyone all of the encrypted data seems like a good place to start.
    - the8472 9y ago
      > side channel attacks created not applicable to offline decryption and of fairly limited use in asynchronous communication > computers get faster, dedicated hardware is created not relevant with 256bit keys. Even grover's algorithm would only cut it down to 128bits which is still "boiling the oceans" territory. So at least in that area we have a lot more safety margin than in the past. Of course none of that is a guarantee that the data will stay secure, but you can't just generalize all attacks used in the past and then count them against a system where we learned from some mistakes and others simply aren't applicable.
- Klathmon 9y ago
  I feel the same. Despite what many people will tell me, handing everything to everyone hidden behind a single crypto lock feels much more dangerous than transmitting it over a wire to only the destination then storing it somewhere that some physical security can apply. It just seems like good security-in-depth. If a flaw were found in the crypto primitives used in my network drive, an attacker would either have had to record all the data as it was being sent, or will need direct access to the drive in question. It's just one extra step that could possibly save you. No cryptosystem is perfect, and relying 100% on just the crypto means that if an attack were found, it would be instantly exploitable to all of your past content without any real ability for you to update or delete it.
- jancsika 9y ago
  > that's your entire message history irrevocably exposed to the world. That's not true. For example, Bitmessage has chans which are essentially mailing lists. In this case the key is supposed to be known/distributed. Recipients use it to read and publish to the mailing list while hiding their list subscriptions and access patterns. That would continue to work even if a flaw in the crypto is found (at least as long as the proof-of-work hashing algo can continue to perform its function without flaw).
- drzaiusapelord 9y ago
  Maybe see I2P-Bote as basic level transport and run S/MIME or gpg with your recipients? If they can use a I2P based email system they can certainly encrypt their mail before sending. Seems like breaking both crypto systems would be unlikely. Meanwhile, smtp is stored and transmitted in plaintext something like 95% of the time. Hacking mail servers, end user PC's, etc to get at someone's mail is a common practice. Pick your poison I guess.
  - admax88q 9y ago
    If you're already going to use gpg or S/MIME then I2P-Bote provides no value IMO. We already have a basic level transport system called IP, and it's quite efficient.
    - drzaiusapelord 9y ago
      You still need a mail server and all that entails, especially in regards to privacy, management, security, etc. With the I2P-Bote, everything is done for you via the hashtable. No domain to buy, no mail server to baby, no working to get off everyone's spam list because you're a new mail server, and no giving up your privacy to google. Even if your smtp message is encrypted you're at least giving up plain-text info like your email address, the recipients email address, your IP, and whatever user-agent or fingerprinting data can be extracted from your browser or mail client.
      - admax88q 9y ago
        I guess that's true. That being said, if you use S/MIME or GPG on top of I2P-Bote that doesn't remove the original stated concern of having all messages stored and accessible to everyone in encrypted form.
MichailP 9y ago
Is there some good and practical (in a form of a textbook) explanation of crypto?
- onli 9y ago
  Practical on which level? If you speak German there is https://www.springer.com/de/book/9783642111860 https://www.springer.com/de/book/9783642111860, one of the better books we used in university. It's not practical in a "how do I program with high level libraries" way, but it explains the crypto itself comprehensibly.
- NoGravitas 9y ago
  Bruce Schneier's _Cryptography Engineering_ (the second edition of his classic _Practical Cryptography_) might be your best bet, depending on how in-depth you want to go. https://www.schneier.com/books/cryptography_engineering/ https://www.schneier.com/books/cryptography_engineering/

74 points by jerheinze 9y ago

I'm always wary of this "publish to everyone, encrypted for the recipient" model (Bitmessage, I2P-Bote, etc) because if somewhere down the line a flaw in the crypto is discovered, that's your entire message history irrevocably exposed to the world.

atemerev 9y ago
If the flaw in the crypto of such magnitude is discovered, the exposure of your message history will be the least of your problems.
- mintplant 9y ago
  That doesn't really do anything to assuage my concern. Crypto bugs are discovered in software all the time.
  - problems 9y ago
    You're right, crypto bugs are discovered in software all the time. However, many of these bugs rely on highly active attacks, oracles, etc. Very few allow offline decryption, For that you'd have to do something incredibly stupid and easy to catch like reuse the same key and IV for multiple messages. Higher level cryptography libraries like nacl prevent these concerns almost entirely.
  - atemerev 9y ago
    Bitcoin core is self-contained crypto bug bounty program :) Rewards are enormous.
- drzaiusapelord 9y ago
  Not really. Not all crypto failures are the math failing or quantum computers suddenly becoming cheap and effective. Its usually just a bad implementation of a solid concept. The bad implementation allows for some side-channel attack and off you go.
niftich 9y ago
Is your concern the same whether a single static key used for the entire message vs. a cryptosystem that offers forward secrecy; or solely based around the idea that having the (encrypted) content publicly disseminated in the first place is an unacceptable risk that enables offline cryptanalysis and, in the case of a very patient attacker, data hoarding? Is your threat model different from, say, a state-level MitM, who today can record IP traffic that happens to include TLS and simply wait the equivalently long time until the underlying ciphers are broken and obsolete? Is the information being exchanged of such sensitivity to require outlasting a typical human lifespan, making the possibility of offline cryptanalysis, enabled by the dissemination of still-encrypted content, an unacceptable risk? If the cryptosystems themselves have comparable properties, do ancillary factors make, say, the I2P DHT usecase worse than the TLS-over-the-public-web usecase, given that a darknet overlay network typically has a self-selecting clientele vs. the vast numbers of people defaultly using TLS, making publicly accessible but encrypted blobs traversing the former more tempting targets in a smaller haystack?
- Klathmon 9y ago
  I can't speak for the parent commenter, but just about every cryptosystem created has made the claim that the data secured will be secure for "longer than a typical human lifespan", and yet time and time again that is shown to be false. Attacks are found, cryptosystems are broken, key strengths weakened, side channel attacks created, computers get faster, dedicated hardware is created, etc... Pretending that we got it 100% right this time seems naive at best, and adding a small amount of "defense in depth" by not giving everyone all of the encrypted data seems like a good place to start.
  - the8472 9y ago
    > side channel attacks created not applicable to offline decryption and of fairly limited use in asynchronous communication > computers get faster, dedicated hardware is created not relevant with 256bit keys. Even grover's algorithm would only cut it down to 128bits which is still "boiling the oceans" territory. So at least in that area we have a lot more safety margin than in the past. Of course none of that is a guarantee that the data will stay secure, but you can't just generalize all attacks used in the past and then count them against a system where we learned from some mistakes and others simply aren't applicable.
Klathmon 9y ago
I feel the same. Despite what many people will tell me, handing everything to everyone hidden behind a single crypto lock feels much more dangerous than transmitting it over a wire to only the destination then storing it somewhere that some physical security can apply. It just seems like good security-in-depth. If a flaw were found in the crypto primitives used in my network drive, an attacker would either have had to record all the data as it was being sent, or will need direct access to the drive in question. It's just one extra step that could possibly save you. No cryptosystem is perfect, and relying 100% on just the crypto means that if an attack were found, it would be instantly exploitable to all of your past content without any real ability for you to update or delete it.
jancsika 9y ago
> that's your entire message history irrevocably exposed to the world. That's not true. For example, Bitmessage has chans which are essentially mailing lists. In this case the key is supposed to be known/distributed. Recipients use it to read and publish to the mailing list while hiding their list subscriptions and access patterns. That would continue to work even if a flaw in the crypto is found (at least as long as the proof-of-work hashing algo can continue to perform its function without flaw).
drzaiusapelord 9y ago
Maybe see I2P-Bote as basic level transport and run S/MIME or gpg with your recipients? If they can use a I2P based email system they can certainly encrypt their mail before sending. Seems like breaking both crypto systems would be unlikely. Meanwhile, smtp is stored and transmitted in plaintext something like 95% of the time. Hacking mail servers, end user PC's, etc to get at someone's mail is a common practice. Pick your poison I guess.
- admax88q 9y ago
  If you're already going to use gpg or S/MIME then I2P-Bote provides no value IMO. We already have a basic level transport system called IP, and it's quite efficient.
  - drzaiusapelord 9y ago
    You still need a mail server and all that entails, especially in regards to privacy, management, security, etc. With the I2P-Bote, everything is done for you via the hashtable. No domain to buy, no mail server to baby, no working to get off everyone's spam list because you're a new mail server, and no giving up your privacy to google. Even if your smtp message is encrypted you're at least giving up plain-text info like your email address, the recipients email address, your IP, and whatever user-agent or fingerprinting data can be extracted from your browser or mail client.
    - admax88q 9y ago
      I guess that's true. That being said, if you use S/MIME or GPG on top of I2P-Bote that doesn't remove the original stated concern of having all messages stored and accessible to everyone in encrypted form.

MichailP 9y ago

Is there some good and practical (in a form of a textbook) explanation of crypto?

onli 9y ago
Practical on which level? If you speak German there is https://www.springer.com/de/book/9783642111860 https://www.springer.com/de/book/9783642111860, one of the better books we used in university. It's not practical in a "how do I program with high level libraries" way, but it explains the crypto itself comprehensibly.
NoGravitas 9y ago
Bruce Schneier's _Cryptography Engineering_ (the second edition of his classic _Practical Cryptography_) might be your best bet, depending on how in-depth you want to go. https://www.schneier.com/books/cryptography_engineering/ https://www.schneier.com/books/cryptography_engineering/