Open Source Embedded SSL - Export Questions

J Harper jsec at peersec.com
Wed Nov 26 17:56:40 EST 2003


Great feedback, let me elaborate.  I realize that AES is implemented in
hardware for many platforms as well.  I'll mention a bit more about our
cryptography architecture below.  Do you know why AES is so popular in
embedded?  ARC4 is faster in software and extremely small code size.  It
seems that trademark issues can be avoided and so cost should not be an
issue.  If RSA is selling RC4, I can't imagine it being very expensive due
to a widely known algorithm that generates the same bytestream.  Hasn't RC4
been milked dry yet :-) ?  Perhaps AES is easy to implement in hardware, and
doing so can reduce power requirements and offload the main processor,
although one would think that the same argument could be made for ARC4, plus
there is additional cost per device for the codec chip.  My guess is that
AES is patent free and provides better security than ARC4, which is
prompting its use:  http://www.faqs.org/rfcs/rfc3268.html

We've designed the interface so it's easy to add new cipher suites, such as
TLS_RSA_WITH_AES_128_CBC_SHA.  We have also layered the cryptography
provider interface so it's easy to plug in specific implementations in place
of the ones we provide.  For example, if running on PocketPC, one could use
the MS Crypto implementation to reduce code size.  Alternatively, "engine"
supported algorithms in OpenSSL could be linked in for higher performance.
We are trying, however to provide the right feature set out of the box, so
AES should definitely go on the list.

The RFC above mentions that AES is an additional cipher suite for TLS.  Our
implementation initially supports only SSLv3.  We can do some testing, but
do you know whether or not it is possible to negotiate to an AES suite over
SSLv3?  My guess is no, because the RFC mentions the SHA HMAC for TLS, not
SSLv3's HMAC.

We've implemented SSLv3 because we wanted the most compatible version of SSL
that was still secure.  Adding optional TLS support would not be a big deal,
but we don't plan it for first release.

    J

----- Original Message -----
From: "Steven M. Bellovin" <smb at research.att.com>
To: "J Harper" <jsec at peersec.com>
Cc: <cryptography at metzdowd.com>
Sent: Wednesday, November 26, 2003 12:09 PM
Subject: Re: Open Source Embedded SSL - Export Questions


> In message <01fc01c3b2f8$c0619500$6a01a8c0 at towelie>, "J Harper" writes:
>
> >SSLv3 protocol implementation
> >Simple ASN.1 parsing
> >Cipher suites:
> >    TLS_RSA_WITH_RC4_128_MD5
> >    TLS_RSA_WITH_RC4_128_SHA
> >    TLS_RSA_WITH_3DES_EDE_CBC_SHA
>
> I understand the need to conserve space; that said, I strongly urge you
> to consider AES as well.  If this is for embedded systems, it will live
> for a long time, and I expect AES to displace 3DES in the near future.
>
> --Steve Bellovin, http://www.research.att.com/~smb
>
>

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com



More information about the cryptography mailing list