RE: applying AES-GCM to secure shell: proposed "tweak"

[James Blaisdell <JBlaisdell%mocana.com@localhost>]

Hey Mouse,

The discussions have been fiery goodness.  I think a good conclusions are being reached.  

You are correct --- the order will likely be a pain, if there are higher prio algos that are not AEAD --- I rationalized the solution as I coded it up (my mistake).  I think having AEAD-* algos ignore hmac algos is likely a good thing.  

I think AES-CTR for the length field is a good least painful approach (option #2); details missing what key to use.  I am certain PKCS#11 will prove to be excruciatingly slow to implement 4-byte AES-CTR jobs, which then means software version needs to be FIPS --- sorry.  For makekey(), maybe same letter e.g. "d", but twice for sub algos?  I'd hate for us to pick just an incremental letter since that will not be future proof (collisions).  

Would AES-CTR be used as a stream cipher, so four lengths would be encipher/decipher per count, or not?  

There are still some open issues even with these alternative approaches.  I am going shut up now.  

Thanks,

James

-----Original Message-----
From: ietf-ssh-owner%NetBSD.org@localhost [mailto:ietf-ssh-owner%NetBSD.org@localhost] On Behalf Of der Mouse
Sent: Wednesday, April 15, 2009 1:10 PM
To: ietf-ssh%NetBSD.org@localhost
Subject: Re: applying AES-GCM to secure shell: proposed "tweak"

> It doesn't need to be ignored, but the order does matter.  AEAD-*
> algorithms must appear first in the order list.

That's completely unextendable; what happens when another algorithm is
added that also "must appear first"?

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B