Doing SSL on an 8-bit processor

Does anyone know of any 8-bit processors that can handle
browser-compatible SSL reasonably quickly?

We have a 44MHz Rabbit 3000 doing initial authentication in 2-3
seconds and throughput of about 120K bit/s (with no Trusted Platform
Module). I'm just curious what else might be out there. - Thanks in
advance

"Brian Murtha" <bmurtha@zworld.com> wrote in message
news:c29d7dc6.0401281736.7f0a99e2@posting.google.com...
> Does anyone know of any 8-bit processors that can handle
> browser-compatible SSL reasonably quickly?

These guys posted here a while back advertising a library for SSL that runs
on 8-bitters: http://www.mocana.com/ssl.html  They claim high portability so
you might try their test drive and see how it works on your hardware /
software.  I asked them directly if they've tested with Dynamic C - they
said their code works with everything, which might mean they've tested it or
it might not.  They might be able to give you some other 8 bit platforms
that their code has been run on.

Dallas has some 8051-based cores with additional crypto hardware.
Xilinx has their picoBlaze 8-bitter with some additional crypto hardware on
one FPGA.
Ateml has AVRs and 6805s with additional crypto hardware.
This doesn't mean someone has a network stack and SSL running on them, but
they are places you might want to look.

> We have a 44MHz Rabbit 3000 doing initial authentication in 2-3
> seconds and throughput of about 120K bit/s (with no Trusted Platform
> Module). I'm just curious what else might be out there. - Thanks in
> advance

Unless you bother to specify the specific algorithms and key lengths you're
timing with, your numbers are too vague to be useful. SSL3 supports a rather
large crypto suite with algorithms for key exchange, stream cipher, and hash
functions, most with configurable key lengths.

Google found this:  http://www.zeus.co.uk/library/technical/hp_bench.pdf
Interesting that they didn't benchmark this against the usual SSL eCommerce
accelerator products.

The last non-crypto-accelerated numbers I remember hearing were back in '96
when I was an eCommerce guy: 0.5 sec for an SSL handshake on a Pentium 150.
Assuming you're only 4-6 times slower than that, that's pretty impressive
for the bunny!

Kelly

"Kelly Hall" <hall@priest.com> wrote in message news:<sH4Sb.19195$p%3.13575@newssvr25.news.prodigy.com>...
> "Brian Murtha" <bmurtha@zworld.com> wrote in message
> news:c29d7dc6.0401281736.7f0a99e2@posting.google.com...
> > Does anyone know of any 8-bit processors that can handle
> > browser-compatible SSL reasonably quickly?
> 
> These guys posted here a while back advertising a library for SSL that runs
> on 8-bitters: http://www.mocana.com/ssl.html  They claim high portability so
> you might try their test drive and see how it works on your hardware /
> software.  I asked them directly if they've tested with Dynamic C - they
> said their code works with everything, which might mean they've tested it or
> it might not.  They might be able to give you some other 8 bit platforms
> that their code has been run on.

The hardware is more critical for speed. The Rabbit 3000A has some new 
instructions that speed up encryption/decryption considerably. Mocana
would be an option for Softools users with some recoding.
 
> Dallas has some 8051-based cores with additional crypto hardware.
> Xilinx has their picoBlaze 8-bitter with some additional crypto hardware on
> one FPGA.
> Ateml has AVRs and 6805s with additional crypto hardware.
> This doesn't mean someone has a network stack and SSL running on them, but
> they are places you might want to look.

Thanks. I'll check them out. I'm curious if they use TPMs. 
 
> > We have a 44MHz Rabbit 3000 doing initial authentication in 2-3
> > seconds and throughput of about 120K bit/s (with no Trusted Platform
> > Module). I'm just curious what else might be out there. - Thanks in
> > advance
> 
> Unless you bother to specify the specific algorithms and key lengths you're
> timing with, your numbers are too vague to be useful. SSL3 supports a rather
> large crypto suite with algorithms for key exchange, stream cipher, and hash
> functions, most with configurable key lengths.

We implented SSL3 and TLS1 with the following, for  out-of-the box
compatibility with all major browsers:

 Secure message digest hashing routines for TLS
 RSA public-key encryption routines (includes PKCS encoding)
 Multi-precision arithmetic for RSA
 RC4 symmetric bulk cipher routines
 SHA-1 message digest implementation
 MD5 message digest implementation

No DES yet.

> Google found this:  http://www.zeus.co.uk/library/technical/hp_bench.pdf
> Interesting that they didn't benchmark this against the usual SSL eCommerce
> accelerator products.
> 
> The last non-crypto-accelerated numbers I remember hearing were back in '96
> when I was an eCommerce guy: 0.5 sec for an SSL handshake on a Pentium 150.
> Assuming you're only 4-6 times slower than that, that's pretty impressive
> for the bunny!

We're pretty pleased with it. We're trying to figure out pricing now.
 
> Kelly

take a look at matrixssl.org

Vadim

"Brian Murtha" <bmurtha@zworld.com> a &#4294967295;crit dans le message de
news:c29d7dc6.0401290911.5c23c830@posting.google.com...
> "Kelly Hall" <hall@priest.com> wrote in message
news:<sH4Sb.19195$p%3.13575@newssvr25.news.prodigy.com>...
> > "Brian Murtha" <bmurtha@zworld.com> wrote in message
> > news:c29d7dc6.0401281736.7f0a99e2@posting.google.com...
> > > Does anyone know of any 8-bit processors that can handle
> > > browser-compatible SSL reasonably quickly?
> >
> > These guys posted here a while back advertising a library for SSL that
runs
> > on 8-bitters: http://www.mocana.com/ssl.html  They claim high
portability so
> > you might try their test drive and see how it works on your hardware /
> > software.  I asked them directly if they've tested with Dynamic C - they
> > said their code works with everything, which might mean they've tested
it or
> > it might not.  They might be able to give you some other 8 bit platforms
> > that their code has been run on.
>
> The hardware is more critical for speed. The Rabbit 3000A has some new
> instructions that speed up encryption/decryption considerably. Mocana
> would be an option for Softools users with some recoding.
>
> > Dallas has some 8051-based cores with additional crypto hardware.
> > Xilinx has their picoBlaze 8-bitter with some additional crypto hardware
on
> > one FPGA.
> > Ateml has AVRs and 6805s with additional crypto hardware.
> > This doesn't mean someone has a network stack and SSL running on them,
but
> > they are places you might want to look.
>
> Thanks. I'll check them out. I'm curious if they use TPMs.
>
> > > We have a 44MHz Rabbit 3000 doing initial authentication in 2-3
> > > seconds and throughput of about 120K bit/s (with no Trusted Platform
> > > Module). I'm just curious what else might be out there. - Thanks in
> > > advance
> >
> > Unless you bother to specify the specific algorithms and key lengths
you're
> > timing with, your numbers are too vague to be useful. SSL3 supports a
rather
> > large crypto suite with algorithms for key exchange, stream cipher, and
hash
> > functions, most with configurable key lengths.
>
> We implented SSL3 and TLS1 with the following, for  out-of-the box
> compatibility with all major browsers:
>
>  Secure message digest hashing routines for TLS
>  RSA public-key encryption routines (includes PKCS encoding)
>  Multi-precision arithmetic for RSA
>  RC4 symmetric bulk cipher routines
>  SHA-1 message digest implementation
>  MD5 message digest implementation
>
> No DES yet.
>
> > Google found this:  http://www.zeus.co.uk/library/technical/hp_bench.pdf
> > Interesting that they didn't benchmark this against the usual SSL
eCommerce
> > accelerator products.
> >
> > The last non-crypto-accelerated numbers I remember hearing were back in
'96
> > when I was an eCommerce guy: 0.5 sec for an SSL handshake on a Pentium
150.
> > Assuming you're only 4-6 times slower than that, that's pretty
impressive
> > for the bunny!
>
> We're pretty pleased with it. We're trying to figure out pricing now.
>
> > Kelly