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

[Ilari Liusvaara <[e-mail]>]

On Sun, Nov 01, 2015 at 01:13:56AM -0700, Dino Farinacci wrote:
> 
> > - 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).
> 
> Yes, both Brian and I replied that we were using this more for
> experimentation on low-powered or CPU challenged devices. We will
> not recommend its use. It’s just there for implementations to start
> with something. But havind said that, I would like to recommend
> the smaller keys that come along with chacha20/poly1305 so maybe
> the subject is moot. 

I think that even having low-security options is a problem.

> > - Instead of "homecooked" encryption, use AEAD modes. AES-GCM is a lot
> >  faster than AES-CBC + HMAC-SHA1-96.
> 
> I didn’t realize we were home cooking this. We can certainly go with
>  AES-GCM. Do you think we should add a new cipher suite for it or
> just change the existing ones that refer to AES-CBC to AES-GCM?

I think just change them.

> > - AEAD_CHACHA20_POLY1305 is not composition of CHACHA20 and POLY1305,
> >  it is a single AEAD algorithm (as is AES128-GCM).
> 
> Did we imply that? Can you point to the text? I for one, am not
> expert enough to know the difference so if text implies that,
> please point that out.

IIRC, the text says something like:

Encryption: Chacha20
Integerity: Poly1305  (i.e. AEAD_CHACHA20_POLY1305)

Which would imply some sort of composition (and the encryption and
decryption procedures also seem to imply it is composition, as
those handle encryption and authentication seperatedly).

> > - The NIST SP800-108 KDF handles the counter and length internally,
> >  those are not part of the context input.
> 
> You should point to text so we know where in the spec you are
> commenting against. It is hard to get context from your comments.

Section 5 in -02. The listing for "Context" (meaning the fields
in context).

> > - 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.
> 
> We use the source RLOC and the Map-Request nonce to identify the association.

That's does not create identifier suitable for comparing between
endpoints for 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
> 
> Because the key-pair is unidirectional. If router A is an ITR and sends
> a Map-Request to router B, that key-pair is for data traffic encapsulated
> from A to B. If B is an ITR encapsulating to A an ETR, a differne
> key-pair is used. A new random number generator, nonce, and key
> exchange is performed for each direction.

You mean that A (and B) is supposed to use different DH keys for
their roles as ITR and ETR (if reusing keys, like at least some
implementations are going to do)?

I didn't see that explicitly required anywhere (this is kind of
thing one wants to document).

The problem if routers share keys between roles is that if two
such routers connect to each other and pick the same nonces (nonce
looks to be only 24 bits!) the keys will collide, with bad
results.

> > - AEAD_CHACHA20_POLY1305 IVs are 12 octets, right? That's too short
> >  to randomly generate. Instead, the encryptor should just use its
> 
> Yes, you are right. I padded to 16-bytes in my implementation. Do
> you see harm in that. That way the packet length/format doesn’t have
> to change for different cipher suites.

Well, no harm to have padding bits (if those are authenticated!). It
is just that such padding needs to be specified.

(Assuming AD for AEAD algorithms is ICV\Encrypt, those are
authenticated)

If you have some AEAD algo with N_MIN > 16 (I don't think any are
currently defined) you could even zero-pad the IV...

> > - Are the associations unidirectional (data is only ever sent one
> >  way) or how is uniqueness of IVs between directions handled?
> 
> Yes, unidirectional. IVs are per packet, any packet, in any direction.

Okay. That reduces IV uniqueness to ensuring each side generates
unique IVs and that the keying material is direction-dependent.
 
> > - 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).

I mean, the document seems to say both IVs are randomly generated and
incremented for every packet (which seem to be mutually
contradictionary).
 
> > - AEAD_CHACHA20_POLY1305 decryption both checks the ICV and if the
> >  check passes, decrypts the data. So performing step 2 also performs
> >  step 5.
> 
> Hmm. So are you saying that if the cipher suite negotiated is chacha20,
> we should not add a ICV? That would be great, beacuse we can make cipher
> suite 4 go even faster.

The encryption with AEAD algorithm presumably goes as follows:

1) The encapsulator generates IV by some method that takes very long
time to repeat (counters, LFSRs, etc...) and appends it to the LISP
header.

2) Invoke the AEAD encryption with:
- Key set to encryption-key
- Nonce set to the IV (truncated to N_MAX octets if N_MAX<16, padded
  with zeroes in the end to N_MIN octets if N_MIN>16).
- AD set to LISP header plus added IV field (the parts of packet marked
  as ICV but not encrypt).
- Plaintext set to the packet payload.

(Any possible tag output is appended to the ciphertext)

3) Prepend the LISP header, together with the IV field into ciphertext.

4) Lastly, prepend the UDP and IP headers into the encrypted packet
and send to destination RLOC.


And decryption:

1) Strip the outer IP and UDP headers.

2) Strip tag encryption concatenated  from packet payload (if any).

3) Invoke the AEAD decryption with:
- Key set to encryption-key (from local key-cache)
- Nonce set to the IV field contents (truncated to N_MAX octets if
  N_MAX<16, padded with zeroes in the end to N_MIN octets if N_MIN>16).
- AD set to LISP header plus added IV field (the parts of packet marked
  as ICV but not encrypt).
- Ciphertext set to the packet payload.

(If the algorithm has tag input, the tag is split off from the
ciphertext).

If the result is FAIL, drop the packet (it is tampered with) and
optionally issue a log message.

3) Strip IV from the packet.

4) Forward the packet to destination EID.
 

The nonce truncation/padding rules are to handle AEAD algorithms
that don't accept 16 octet nonces but still keep the IV on
wire at constant 16 octets.

There is also AEAD_AES_128_GCM, which being AEAD algorithm, is used
similarly to AEAD_CHACHA20_POLY1305. The above algorithms work with
it too.



-Ilari