I did a review of crypto usage of lisp-crypto (-02), and found the following issues (some I have noticed before, some were new to me):
- Ciphersuite 1 uses 1024-bit Diffie-Hellman, which is too weak (after you have cracked one key (and it doesn't take that much, especially if you can throw ASICs at the problem), you can crack each subsequent one in a few CPU minutes. With 2048-bit DH, at least the first key tends to be too hard, and with ECDH, tricks like this don't work). - Instead of "homecooked" encryption, use AEAD modes. AES-GCM is a lot faster than AES-CBC + HMAC-SHA1-96. - AEAD_CHACHA20_POLY1305 is not composition of CHACHA20 and POLY1305, it is a single AEAD algorithm (as is AES128-GCM). - How to encode Diffie-Hellman public keys? I presume big-endian integer encoding. - Don't truncate Diffie-Hellman secret, just feed the entiere thing to the KDF. - The NIST SP800-108 KDF handles the counter and length internally, those are not part of the context input. - If you need identifier for association (e.g. for displaying to admin for authentication purposes), you must hash in the (EC)DH public keys used into the identifier. Otherwise MITM attacker can defeat the authentication. - If the same system can be ITR and ETR at once, how one ensures that if two such systems establish associations to each other, the keys won't wind up being the same? This could be solved by requiring separate keys for ITR and ETR operation, or including the public keys in the context in fixed order (e.g. first ITR, then ETR). - AEAD_CHACHA20_POLY1305 IVs are 12 octets, right? That's too short to randomly generate. Instead, the encryptor should just use its preferred generation method that takes long time to cycle (counter, 96-bit LFSR, etc...). - Are the associations unidirectional (data is only ever sent one way) or how is uniqueness of IVs between directions handled? - IV is incremented for every packet? If using CBC mode, predictable IVs are bad (AEAD algorithms do deal with predictable IVs, but not repeating IVs). - What one does feed into "AD" input of AEAD_CHACHA20_POLY1305? Everything that is marked as ICV but not Encrypt? Or just the LISP parts? (One doesn't need to authenticate the IV, but it can sometimes be easier to authenticate it). - AEAD_CHACHA20_POLY1305 encryption already splits out the ICV (a.k.a. tag). - AEAD_CHACHA20_POLY1305 decryption both checks the ICV and if the check passes, decrypts the data. So performing step 2 also performs step 5. - I don't see requirement that ITR nonces must be distinct for the same ITR DH key (otherwise encryption keys will be the same if the ETR DH key is the same)? - The CHACHA-POLY reference should presumably point to RFC7539? - Maybe use the CFRG-CURVES draft (in RFC-EDITOR queue) for Curve25519/X25519. -Ilari _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
