3 ms·

Looks really cool. A bit surprised no one here told you to "not roll your own crypto yet". Great that you specified the protocol and threat model in any case. W

• progre 4y ago
  I think most people mean "don't roll yor own and use it in production" Writing your own crypto for fun should be encuraged.
• latenightcoding 4y ago
  Author is not rolling their own crypto. They are using libsodium.
  • touisteur 4y ago
    Almost as fun as SPARK's own Rod Chapman doing some tweetnacl porting and proof https://blog.adacore.com/sparknacl-two-years-of-optimizing-crypto-code-in-spark-and-counting https://blog.adacore.com/sparknacl-two-years-of-optimizing-c...
• markdascher 4y ago
  > Why 12288 bytes for p0? Good question! Tripling the first block's size (12288=3x4096) happened the most recent commit, to make all of the Padmé sizes possible. https://codeberg.org/markdascher/moochacha/commit/3145d7fb95ea1d4cdaef669c1c3bf2e978395c3b https://codeberg.org/markdascher/moochacha/commit/3145d7fb95... The original encrypted format was more straightforward: 32 + 4112 + 4112 + ... + (last block, less than 4112) bytes. That initial 32-byte seed messed up the math just enough that a 2 MiB output was impossible. (It would require the last block be exactly 4112 bytes, which isn't allowed.) If those extra 32 bytes weren't there, then it's a lot easier to calculate the impossible sizes, since they're just multiples of 4112. And those never collide with Padmé, at least for all 64-bit file sizes. I like to think of that first block as 32+12288+16, getting block boundaries lined back up on even multiples of 4112.