Thoughts on cipher selection

I'm still reading the archive so I may make assumptions from areas that have
prior to this been fixed.

About Stream versus Block cipher debate. There seems to be a large lack of a
solid foundation in this, so if you'll let me go a bit beyond what I would
normally assume the scope to be, and please permit me to go probably well
below the level of knowledge already attained by everyone here. First a
block cipher is a reversible operation performed on a block of data based on
some data called a key, some common examples of block ciphers are DES,
Rijndael, and Blowfish. A chaining method (aka Chaining Mode) is a way of
changing the encryption between blocks, the simplest form is ECB where there
is no change in either key or data between blocks, CBC is also very common
where the previous encrypted data is used to change the process. A stream
cipher is very much a method of very advanced chaining, however it is
uncommon to make full use of this because stream ciphers are still very
experimental, in this case the chaining mode is generally applied to the
plaintext using just an XOR operation, the most common example is ARCFOUR
(only because it must technically be seperated from the RC4 that is still an
RSADSI trade secret). Either a block or a stream cipher can be used to
encrypt a block or a stream of data.

About AES. Although the announcement that Rijndael will be AES has already
been made, the original call for AES papers specified a 128-bit block
cipher, accepting 128, 192, or 256-bit keys, so any AES candidate will meet
these requirements. Now that Rijndael has been named AES, it is clear that
AES also has a possibility of having a 128, 192, or 256-bit block that is
encrypted, however only the 128-bit block will be officially marked as AES
in the first edition.

About selecting block ciphers. I believe that embedding the name, key size,
and block size (and perhaps version number), of the cipher used is of the
upmost importance, this prevents us from stepping in the typical trap of
having to revisit this standard in 30 days and changing our ciphers. However
a base requirement is very necessary, I feel that AES (Rijndael) is an ideal
choice, and that to conform to the upcoming FIPS we would have to require
implementation of 128, 192, and 256-bit AES. Any other block/stream ciphers
should be optional.

Stream ciphers, I personally have a problem with modern stream ciphers, they
are very subject to a bit-flip attack, which makes them unacceptable for
most uses. However many people have a particular affinity towards them, to
that end I suggest we make ARCFOUR (or RC4) mandatory, and give it two
names, RC4 and ARCFOUR, in order to acknowledge that RSADSI actually does
still own the tradesecret on RC4, and to recognise that it is no longer
secret.

NULL encryption. Not usually necessary, but to make use of some of the more
advanced public key algorithms it becomes conceptually easier. To this end I
suggest we make a NULL encryption optional, and only allow it's use where it
will make the system itself conceptually easier. By example take
multi-target ECDH (Ellyptic Curve Diffie Hellman Exchange, aka ECC or
Ellyptic Curve Cryptography), it is conceptually very proper to use it to
key AES (so a possible name is ECDHAES), use that to encrypt a NULL
encrypted key block, which may for some people be conceptually easier than
AESdecrypt(SHA-256(ECDH), key). If it is decided that the NULL encryption is
not necessary I will not regret seeing it go.

Public key encryption. This is a bit more complicated. Of course we need to
support RSA-OAEP, but we should also support EC-ElGamal, XTR, NTRU, ElGamal,
RPK, ACE, LUC-ElGamal, etc. If we place the name of the algorithm in the
actual descriptive block, then it allows for implementors to add algorithms
as necessary. By forcing the addition of RSA-OAEP we gaurentee that there is
at least one algorithm that will be shared between any two entities.

Key Negotiation. I personally find this very important, however there are so
many complicating factors that each one will have to be addressed
individually. There is fully-authenticated-DH, half-ephemeral-DH,
full-ephemeral-DH, MQV-full-auth-DH, MQV-half-ephemeral-DH,
MQV-full-ephemeral-DH, the same for LUC-DH, ECC-DH, XTR, LUC-XTR, at least 5
variants of RSA, plus several dozen more obscure papers which will apply to
each and every one, and I haven't even addressed the curve differences for
ECC. So I thinkwe should severely limit ourselves in this realm, LUC based
systems are virtually unused, XTR is very much up and coming so needs to be
supported, ECC-DH (sometimes called ECDH) needs to be supported and DH needs
to be supported, these should all be supported in their fully-authenticated,
and half-ephemeral modes, full-ephemeral is not particularly applicable.

Message Authentication Codes. These would be the most likely method of
determining validity of embedded encrypted data, because of their speed. By
encrypting one along with the data, the data can be certified as intended,
and a signature across the entire document can assert that it has been
unaltered. I propose using UMAC as the required, and allowing the addition
of others as the implementer sees fit. By using these we could eliminate the
need to properly canonicalize encrypted data through encryption, resulting
in a format that is much easier to deal with.

Did I miss any necessary building blocks?
                    Joseph Ashwood
                    Arcot Systems Inc
                    www.arcot.com

Received on Tuesday, 12 December 2000 21:56:48 UTC