Subject: Re: additional core draft nits in need of WG attention.

From: [email-masked]
Date: Tue, 11 Nov 2003 22:37:33 -0800 (PST)

On 11 Nov, Bill Sommerfeld wrote:
> - what proportion of the code size of a "minimized" implementation is
> the actual algorithm code?  i.e., are we talking 1% or 10% bloat here?

In our smallest java-client, which is used on cellphones etc, the actual
AES-code makes up between 1% and 0.5% depending on how you count. The
DES and 3DES-code is about twice that big.

> - how widespread is AES support today?

IMHO it is pretty widespread, at least among modern versions.
Unfortunately, as well all know, the installed base may be far behind.
For exampel we still get a lot of questions on SSHv1 support:-(

	/MaF
-- 
Martin Forssen <[email-masked]>              Development Manager
Phone: +46 31 7744361                         AppGate Network Security AB

---

From: [email-masked]
Date: Sun, 16 Nov 2003 10:48:48 +0100 (CET)

On 15 Nov, Bill Sommerfeld wrote:
> (The process for advancement to Draft Standard requires that we
> document that all of the protocol features interoperate.  if nobody
> has actually implemented asymmetric algorithms, we can strike it at
> that point).

Actually now that I think about it MindTerm does support asymmetric
algorithms. I just tested it againt OpenSSH and it seems to work. I used
different encryption algorithms, hash-algorithms and one direction used
compression while the other did not.

But I have no strong feelings on how we should treat this feature in the
drafts.

	/MaF

---

From: [email-masked] (Peter Gutmann)
Date: Thu, 20 Nov 2003 17:43:26 +1300

Jon Bright <[email-masked]> writes:

>Peter Gutman didn't mail to say whether his implementation supports AES or
>not (since his policy is to support as little as possible,

Whatever gave you that impression?  I support anything that (a) makes sense
(for example supporting telnet options in a non-interactive, non-telnet app
isn't very useful) and (b) isn't a potential security problem.  In the case of
AES I support it in the client (as a second choice after 3DES), but it's
currently commented out in the server because the client gets to choose the
algorithm, so even if the server advertises AES as its least-preferred choice
the client always latches onto that (by specifying it as its most-preferred
one) and the server has to use AES anyway.  Once it passes the five-year test
(five years from publication/release without serious weaknesses discovered)
I'll uncomment it, and people who always want to use AES can always uncomment
it themselves.  Apart from that I do the stuff I described in an earlier
message: { "whatever the user has enabled" union "3des, blowfish, cast, idea,
rc4" } alongside any custom algorithms the user (meaning the person who built
the code) has added.

Peter.