On 2011-07-27 14:39, David McGrew wrote: [...] > RFC 5116 defines a standard interface to Authenticated Encryption with > Associated Data (AEAD) algorithms, which is used by TLS 1.2, SSH, > SRTP, IKE, and SMIME, and is backwards compatible with ESP. The AEAD > interface is simple (two defined messages, four inputs and one output > each), and AEAD is widely regarded as the state of the art in security > and efficiency (including both OCB and GCM, for instance). It appears > that CICM is not compatible with this interface, in which case it > would be a real step backwards. (If CICM does support AEAD, it is not > clear to me how it does. Am I missing something?) > > CICM is intended for use in a high assurance crypto module. > Considering that AES-GCM is required for Suite B, and the Suite B RFCs > all cite RFC 5116, the lack of AEAD support appears problematic. [...]
I've read through RFC 5116 and there doesn't seem to be any reason why CICM couldn't support AEAD, although it would probably have to be its own channel type. Here's why: 1. AEAD encryption takes a key (K), a nonce (N), plaintext (P), and associated data (A) and outputs ciphertext (C). Decryption takes K, N, A, and C and returns P (or FAIL). (Simplicity itself!) 2. Since the associated data (A) is sent in the clear, this is similar to a CICM::EncryptBypass::Conduit, although the whole bundle is authenticated, so it is more like a CICM::Encrypt::WithMACConduit --albeit with a single key (K). See: http://tools.ietf.org/html/draft-lanz-cicm-cm-01#section-9.8 http://tools.ietf.org/html/draft-lanz-cicm-cm-01#section-14.5 3. Therefore, it seems like the best way to handle AEAD would be to create a new channel type. Specifically, we'd need to support creating a conduit just like an EncryptBypass::Conduit (one key, one algorithm) that behaved like an Encrypt::WithMACConduit (supporting the end_get_mac() method). CICM::Status create_encrypt_auth_data_conduit( in CICM::RemotePort remote_port, in CICM::SymKey key_ref, in CICM::SymEncrAlgorithmId algorithm, out CICM::EncryptBypass::AEADConduit conduit_ref ); The conduit would look exactly like a Encrypt::WithMACConduit, except that both key attributes (key, mac_key) would point to the same key. For example, interface AEADConduit : CICM::AbstractMACConduit, CICM::Encrypt::Conduit {} 4. The approach above would differ from RFC 5116 in a few ways: - There is not a single method with four inputs that returns a single output. This is because in CICM channel *creation* is separate from channel *usage*. - The output is not returned, but is emitted in another domain. If necessary, we can add a similar channel type to the CICM::Coprocessor namespace as we have for Coprocessor::EncryptWithMACConduit. The conduit would no longer require a remote port, and the conduit would inherit from CICM::Coprocessor::EncryptConduit rather than CICM::Encrypt::Conduit. See: http://tools.ietf.org/html/draft-lanz-cicm-cm-01#section-18 http://tools.ietf.org/html/draft-lanz-cicm-cm-01#section-18.3 http://tools.ietf.org/html/draft-lanz-cicm-cm-01#section-18.4 - Additionally, the nonce (N) parameter would be omitted, but could be supplied or generated using the attributes and methods inherited from CICM::SetVectorController and CICM::GenVectorController. See: http://tools.ietf.org/html/draft-lanz-cicm-cm-01#section-7.5 http://tools.ietf.org/html/draft-lanz-cicm-cm-01#section-7.6 ** David McGrew: - Is my understanding of how AEAD works correct? - Would these sorts of additions satisfy the needs of AEAD, or would a more explicit conformance to the method signature be required? Lev _______________________________________________ cicm mailing list [email protected] https://www.ietf.org/mailman/listinfo/cicm
