neemek/hermes
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

update readme nonce-reuse

Browse source
This commit is contained in:
Neemek 2025-11-08 21:32:16 +01:00
parent 4d3bd0995f
commit 59b836b501
1 changed files with 1 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

1
README.md
View file

@ -11,6 +11,7 @@ i mek protokol (pls don't guillotine me, is for fun)
- you would need to seed it with something else than *just* the shared key, or else the output would be completely predictable and an attacker could easily decrypt all your traffic if they manage to get the secret key (if they get the secret key, then your data is probably screwed anyways). however, if the nonce is ephemeral (not saved), and reasonably unpredictable for an attacker, then that would mean they would have to search up to $2^{96}$ blocks in order to get the data. its *nothing* compared to the secret key ($2^{256}$), and it is *not* where the security of the protocol or the chacha stream cipher should be derived.
- seeding it with the mac or using the hash of the previous message(s) would mean that if they were to replay or repeat the same message blocks, then an attacker would be able to see the same pattern of messages. it would also make it vulnerable to replay attacks, where an attacker could replay a message to the server, given that they somehow know the same nonce is reused.
- the benefit of depending on some other method that would produce the same results on each end is that a malicious user would be unable to send a bogus nonce that has already been used. may not be a problem, since the server shouldn't send information that is so sensitive that the client sharing it with a third party would be detrimental for the server.
- the problem of a pseudorandom function that is seeded from the start is that both parts now have to keep track of some state. If they become unsynchronized, they would have no (straight-forward) way of synchronizing (achieving same state), so the connection would have to be aborted and retried.
- in message header (would mean ~~a lot more~~ *a bit more* (12 bytes isn't that much, and it's probably not wise to prematurely optimize it away) data being sent)
- should it be public? or should it be sent encrypted with prev. msg?
- having it public wouldn't be the end of the world, but if it were, an attacker would know when two blocks are encrypted with the same nonce. the chance of two nonces being the same is $2^{-96}$, so it's not exactly something to be scared of.