
I2P-Bote – Email plugin for the I2P network that uses a distributed hash table - jerheinze
https://i2pbote.xyz/
======
mintplant
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.

~~~
niftich
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
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
> 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.

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

~~~
onli
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.

