John: Would the following text for AES-CTR resolve your concern raised in your last comment?
When AES-CTR is used as a COSE Content Encryption algorithm, the encryptor generates a unique value that is communicated to the decryptor. This value is called an initialization vector (IV) in this document. The same IV and AES key combination MUST NOT be used more than once. The encryptor can generate the IV in any manner that ensures the same IV value is not use more than once with the same AES key. When using AES-CTR, each AES encrypt operation generates 128 bits of key stream. AES-CTR encryption is the XOR of the key stream with the plaintext. AES-CTR decryption is the XOR of the key stream with the ciphertext. If the generated key stream is longer than the plaintext or ciphertext, the extra key stream bits are simply discarded. For this reason, AES-CTR does not require the plaintext to be padded to a multiple of the block size. AES-CTR has many properties that make it an attractive COSE Content Encryption algorithm. AES-CTR uses the AES block cipher to create a stream cipher. Data is encrypted and decrypted by XORing with the key stream produced by AES encrypting sequential IV block values, where the first block of the key key stream is the AES encryption of the IV, the second block of the key stream is the AES encryption of (IV + 1) mod 2^128, the third block of the key stream is the AES encryption of (IV + 2) mod 2^128, and so on. AES-CTR is easy to implement, and AES-CTR can be pipelined and parallelized. AES-CTR also supports key stream precomputation. Sending of the IV is the only source of expansion because the plaintext and ciphertext are the same size. When used correctly, AES-CTR provides a high level of confidentiality. Unfortunately, AES-CTR is easy to use incorrectly. Being a stream cipher, reuse of the IV with the same key is catastrophic. An IV collision immediately leaks information about the plaintext. For this reason, it is inappropriate to use this AES- CTR with static keys. Extraordinary measures would be needed to prevent reuse of an IV value with the static key across power cycles. To be safe, implementations MUST use fresh keys with AES-CTR. AES-CTR keys may be obtained either from a key structure or from a recipient structure. Implementations encrypting and decrypting MUST validate that the key type, key length, and algorithm are correct and appropriate for the entities involved. With AES-CTR, it is trivial to use a valid ciphertext to forge other (valid to the decryptor) ciphertexts. Thus, it is equally catastrophic to use AES-CTR without a companion authentication and integrity mechanism. Implementations MUST use AES-CTR in conjunction with an authentication and integrity mechanism, such as a digital signature. Since AES-CTR cannot provide integrity protection for external additional authenticated data, the decryptor MUST ensure that no external additional authenticated data was supplied. Russ > On Jan 17, 2023, at 8:23 PM, Russ Housley <[email protected]> wrote: > > John: > > Thanks for the careful review. > >> This is useful. Thanks for driving this. Some comments: >> >> >> - RFC 8152 is obsolete > > Yes, RFC 9052 was published. I'll reference that. > >> - "NIST has defined several modes of operation for use with AES [MODES]. >> Each of these modes has different characteristics. The five modes >> are: ECB (Electronic Code Book), CBC (Cipher Block Chaining)..." >> >> Mentioning ECB as a NIST defined method without stating anything more is >> dangerous. Some might think it gives similar properties as CTR and CBC and >> use it instead. NIST now finally states that "the use of ECB to encrypt >> confidential information constitutes a severe security vulnerability", which >> should have been done a long time ago. I suggest removing all mention of ECB >> and just write that CTR and CBC are two modes of operation defined by NIST. >> https://csrc.nist.gov/news/2022/proposal-to-revise-sp-800-38a >> <https://csrc.nist.gov/news/2022/proposal-to-revise-sp-800-38a> > Good point. I will gladly drop ECB from the listed modes. Of course, there > was never an intent to assign a code point for ECB. > >> - "This document specifies AES-CTR and AES-GCM" >> Should be AES-CBC > > This typo is fixed. > >> - "For example, the same keying material must not be used with AES-CTR and >> AES-GCM." >> Not wrong, but maybe you meant CBC here as well? > > Yes. That typo is fixed too. > >> - "Since AES-CTR cannot provide integrity protection for external >> additional authenticated data" >> It cannot provide integrity protection for COSE internal aad either. Can >> AES-CTR be used with protected headers? Should the implementor still create >> an Enc_structure? > > The real point is at the send of the sentence: > > Since AES-CTR cannot provide integrity protection for external > additional authenticated data, the decryptor MUST ensure that no > external additional authenticated data was supplied. > > I think we do want to define an alternative for Enc_structure. Wouldn't that > be even more disruptive to implementation that wants to support AES-CTR or > AES-CBC? > >> - "Since AES-GCM uses AES-CTR for encryption, an attacker can switch the >> algorithm identifier from AES-GCM to AES-CTR" >> >> An attacker can also switch other header parameters such as content type, >> kid, IV, Partial IV, kid context, etc... >> >> The draft should probably make recommendations on integrity protecting all >> header parameters with the mandatoty authentication and integrity mechanism. >> Or fixing them outside of COSE. > > It already does: > > With AES-CTR, it is trivial to use a valid ciphertext to forge other > (valid to the decryptor) ciphertexts. Thus, it is equally > catastrophic to use AES-CTR without a companion authentication and > integrity mechanism. Implementations MUST use AES-CTR in conjunction > with an authentication and integrity mechanism, such as a digital > signature. > > and: > > AES-CBC does not provide integrity protection. Thus, an attacker can > introduce undetectable errors if AES-CBC is used without a companion > authentication and integrity mechanism. Implementations MUST use > AES-CBC in conjunction with an authentication and integrity > mechanism, such as a digital signature. > > and: > > This document specifies AES-CTR and AES-GCM for COSE, which are not > authenticated encryption with additional data (AEAD) ciphers. The > use of the ciphers is limited to special use cases where integrity > and authentication is provided by another mechanism, such as firmware > encryption. > >> - AES-CTR seems less specified than the other COSE encryption algorithms >> including AES-CBC. The IV length is not specified, and it is not specified >> how to combine initial IV with the block counter (or LFSR). Given COSE with >> AES-GCM, and IV, and a key, two implementations can talk to each other. This >> is not true for the AES-CTR COSE algorithm as currently specified. As they >> anyway need to agree on an external integrity algorithm this is not a big >> problem, but it should probably be mentioned. > > The initial block of key stream is clearly defined by the IV. If we remove > the option to use an LFSR, and instead always determine the next counter > value by + 1 mod 2^128. Would this resolve the concern? > > The LFSR came about from RFC 3686, where the counter space is divided in a > manner that the first part totally under the control of the sender, so there > was no need for the sender and receiver to agree on the way that it is > computed. That is not really the situation here, > > Russ > > _______________________________________________ > COSE mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/cose
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
