Hermes

i mek protokol (pls don't guillotine me, is for fun)

bad things (that i should really fix)

• no verification of authenticity
  • message/MAC (poly1305?)
  • server/client (static keys)
• protocol structure
  • how to prevent nonce reuse/how to get shared nonce? (current version uses one nonce for the entire connection :P)
    • pseudorandom function? (but how would you seed it??? shared key?)
      • 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.
      • better to rely on /dev/urandom made by people who actually know their shit and who do have experience (also isn't based on my arbitrary schemes; keep it simple stupid (unless you have a very good reason not to))
    • based on message content/MAC? hashing???
      • eh, not that effective at preventing nonce reuse
• no fucking tests (dummy servers and clients?)
  • how tf would i know if i break something???
  • except for manually testing ofc.

things that would be sick but also idk if i have the time or willpower before my attention gets taken by other shit i really want to do like implementing a post-quantum secure KEM (maybe KYBER..)

• custom blake3 implementation (~ IM NOT A BIG FAN OF THE GOVERNMENT ~)
• custom poly1305 implementation (it would be fine to use one from crates.io, but it would be so awesome, it would be so cool if i made it myself :D + fun)
  • that was actually surprisingly simple