Subject: [lisp] Let's review crypto in lisp-crypto

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 28 Oct 2015 16:17:03 +0200

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