Re: [Cfrg] Adoption call for draft-barnes-cfrg-hpke

[Paul Lambert <[e-mail]>]

The area of ‘hybrid’ encryption is an important topic and I support the adoption of this work area the CFRG.

The current  'draft-barnes-cfrg-hpke-01’ does have some issues …
 - the first draft was a bit easier to read. the current ’setup’ should be removed/rewritten
 - KEM abstraction is unnecessary and seems to be adequately covered by the DH_Group
 - the PSK mode goals and use cases is unclear
 - PSK mode should use a Security Context Indicator (versus key id). The ’sci’ could be derived from a prior hike message.
 - use case/requirements are lacking …e.g.  should the mechanisms support firmware encryption (word alignment requirements, header requirements)
 - the stateful nature of the encryption risks making this a full key exchange and messaging protocol … maybe not a problem
 - using Initator and Responder does not work well for describing local processing. It’s more consistent for processing to refer to local keys (e.g. my_public_key) and peer keys.
 - it’s not obvious from the draft how the secret key on sent messages uses a different context than the received message. 
   There needs to be two secret keys defined to make this clear.
 - the len(KemContext) is defined as a one byte encoding, but one of the modes has >255 context bytes. This should be a 4 byte little-endian encoding.

Since the draft was written in a Python-like pseudo code, I’ve addressed the issues above in a working Python implementation: 

https://github.com/nymble/hpke/blob/master/hpke.py  

The KEM and ’setup’ functions did not add clarity and these processing steps were implemented in-line (see below). I suspect that the draft would read much better if these were removed.

Some additional comments:
 - The sequence number usage creates a very fragile protocol. The service interface and impact of the communication channel needs consideration.
 - design is not suitable for very large files or small processors
   - validity of header should be able to be validated before processing full encrypted data
   - major fields should be word aligned
   - message layout for in-place encryption/decryption should be considered
- The NIST based cipher suites could be using x-coord encoding for better efficiency
- The AEAD abstract prevents better control/placement of the IV and MAC fields (e.g. MAC always at end)
- Nonce misuse resistant algorithms should be considered as an alternative to keeping sequence number state (e.g. SIV modes)



Paul



—— HPKE wrap … working implementation including one minor message formatting change.

def wrap(self, pt, aad=None, auth=True):
        """ Encrypt using AEAD the plain text 'pt' to the 'peer_pk'
            and return cipher text 'ct'.
        """
        ephemeral_key_pair = self.cipher_suite.DH_Group.generateKeyPair()    # generate the ephemeral key pair

        # definitions for for readability ...
        cs = self.cipher_suite
        marshal = cs.DH_Group.marshal
        hash_length = cs.Hash.digest_size
        info = self.info
        csi = cs.csi # octets
        pkP = self.peer_key
        skE = ephemeral_key_pair    # key pair object used in API rather than private key
        pkE = ephemeral_key_pair.public_key
        skM = self.my_key_pair      #  'M' for secret key of My key pair
        pkM = self.my_key_pair.public_key
        DH  = cs.DH_Group.dh
        KDF = cs.KDF
        Nk = cs.AEAD.key_length
        Nn = cs.AEAD.nonce_length
        
        salt = hash_length * b'\x00'  # all zero octet string
        enc = marshal( pkE )
        
        if auth:                        # authenticated
            mode = MODE_AUTH
            shared_secret = KDF.extract( salt, DH(skE, pkP) + DH(skM, pkP) )
            kemContext = enc + marshal( pkP ) + marshal( pkM )
            sci = KDF.extract( salt, csi + mode + marshal( pkP ) + marshal( pkM ) )

        else:                           # unauthenticated
            mode = MODE_BASE
            shared_secret = KDF.extract( salt, DH(skE, peer_pk) )
            kemContext = enc + marshal( pkP )
            sci = KDF.extract( salt, csi + mode + marshal( pkP ) )
        
        context = csi + mode + blen(kemContext) + kemContext + blen(info) + info
        snd_secret = KDF.expand(shared_secret, b'hpke key'   + context, Nk)
        snd_nonce  = KDF.expand(shared_secret, b'hpke nonce' + context, Nn)
        aead = cs.AEAD( snd_secret )
        snd_seq_bytes = pack( '<L', self.snd_seq )   # little-endian to simplify zero padding by bxor        
        nonce = bxor( snd_nonce, snd_seq_bytes )

        ct = csi + mode + b'\00' + enc + aead.seal(nonce, aad, pt)       #

        self.snd_seq += 1
        
        return ct


Paul





> On Apr 26, 2019, at 1:09 AM, Paterson Kenneth <[e-mail]> wrote:
> 
> Dear CFRG,
> 
> (This is the first of two adoption calls today.)
> 
> This email starts a 2-week adoption call for:
> 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dbarnes-2Dcfrg-2Dhpke-2D01&d=DwICAg&c=qgVugHHq3rzouXkEXdxBNQ&r=oIg4FfS8P761BlhMPJ2ys3IvSyH4XQ12Mbj_mXrCAJs&m=Wh8bn9aCR4-MFtTP5yCwkeaQZqO2PAOTRibf5ydPXHw&s=tv3ZjsWTM-r7Yk_XfD-Cgcd8aVedPNI9Ekt2_Q1vbM0&e=
> 
> Hybrid Public Key Encryption
> 
> Please give your views on whether this document should be adopted as a CFRG draft, and if so, whether you'd be willing to help work on it/review it.
> 
> Thanks,
> 
> Kenny (for the chairs)
> 
> 
> _______________________________________________
> Cfrg mailing list
> [e-mail]
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.irtf.org_mailman_listinfo_cfrg&d=DwICAg&c=qgVugHHq3rzouXkEXdxBNQ&r=oIg4FfS8P761BlhMPJ2ys3IvSyH4XQ12Mbj_mXrCAJs&m=Wh8bn9aCR4-MFtTP5yCwkeaQZqO2PAOTRibf5ydPXHw&s=HD8zv1ivtjPaqEeGlOHxvARItXMw6_tBhK7SLcXXckw&e=