[Cryptography] a question on consensus over algorithmic agility

Phillip Hallam-Baker phill at hallambaker.com
Wed Jun 25 19:48:32 EDT 2014


On Wed, Jun 25, 2014 at 11:01 AM, ianG <iang at iang.org> wrote:

> Hi all on the crypto group,
>
>
>
> over on TCPcrypt [0] it is being debated whether Algorithms should be
> Agile [1] for a future extension of TCP that includes opportunistic
> encryption.
>
> It has been claimed that the consensus is that algorithms MUST be agile.
>  And, ditto for TCPcrypt, being a lightweight MITMable protocol.
>
> My question in 2 parts, purely to measure *consensus in this group* as
> opposed to the IETF group:
>
>
>      1.  Do you believe that in general case for the security for the
> net, (a) security protocols MUST be agile w.r.t cryptography ciphers ?
> OR, in the negative, no, protocols may set one cipher and stick with it.
>

Neither,

Exactly one preferred algorithm and one backup algorithm per crypto
function and this should be consistent across all protocols.

A problem with mix and match crypto is that people mess up with assumptions
such as stream ciphers being secure against known plaintext attacks and
such. 'Never send a stream cipher to do a block cipher's job' as Jon Callas
said to me once.

Then there are the attacks against the negotiation mechanism.


This is a draft I was asked to write on this but nobody seemed interested
after...

http://tools.ietf.org/html/draft-hallambaker-consensuscrypto-00

The idea here is that there would be two algorithms, a primary and a backup
that are MUST and SHOULD compliance requirements. Specifications must still
be agile to allow the use of any algorithm but the mechanism need not be
efficient or pretty. So I would have no qualms about requiring algorithms
to be specified by ASN.1 OID injected into the slot for ciphertext as a
prefix and junk all the per protocol algorithm registries.




>      2.  Do you believe in the specific case of an opportunistic,
> dynamic, transparent upgrade inside TCP to an (e.g.,) anonymous DH
> protected secret key protocol, that, the ciphers must be agile?  OR, in
> the negative, no, that particular protocol can insist on only one and be
> done with it.
>

I am not sure what the question is here.

I certainly don't believe in frameworks for negotiating key exchange
mechanisms. Just have one algorithm and do the job right.

When we designed IPSEC, PGP and S/MIME RSA was expensive. Even at 1024 bits
it was a notable machine drag. Today I was testing a key manager for
Prism-Proof-Email which generates 4 2048 bit keys when it initializes a
user's personal PKI hierarchy and found it was only a minor inconvenience
testing the registry setting routines.

In 1995 the choice to do an ephemeral key exchange made sense. Today, just
do it, it will take longer to find out if you need it than to just do it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20140625/240ef74f/attachment.html>


More information about the cryptography mailing list