On Sat, Aug 02, 2014 at 05:27:35PM -0700, Watson Ladd wrote: > > The second one is implementable and deployable. It has the > disadvantage of not being deployed > yet, and the crypto could stand some major improvements: I've only > just begun to look at it, and > parts of it seem insecure. (Poly1305 MAC eats a nonce. Where is this > nonce? It's not a PRF: > does this break the XOR scheme? Note the security proof doesn't apply > in this case)
Also, the algorithm notation seems pretty opaque. Some other areas of concern / possible improvements: - RSA: Keygen is very expensive, decryption is expensive, getting session IDs right with that seems bit tricky. - DH functions: Could use modern fast one (but probably not really cutting- edge stuff[1]). - Session IDs: Those are awfully easy to get wrong (one can't assume Diffie- Hellman is collision-resistant, and I don't want to even think of RSA). - Ciphers: Chacha20-based ciphers could be useful for CPUs with no AES (and also as backup for AES). - TCP simultaneous open: Always a fun surprise. [1] Like HECDH (seems limited to 128-bit level) or HaECDH (I don't think there are good curves yet). -Ilari _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
