On Tuesday 22 March 2016 09:48:51 Peter Gutmann wrote: > Joachim Strömbergson <joac...@secworks.se> writes: > >When you say that "a Cortex M3 isn't going to be able to handle > >RSA-2048", what do you mean specifically? Considering that it is > >being done by for example SharkSSL [1], is supported by ARM mbed TLS > >(nee PolarSSL) [2] I fail to see what hardware limits you are > >seeing. Yes, the speed you get is not impressive (1-2 seconds to > >decrypt), but it might be ok, depending on your application. > > It's not just RSA, it's DH as well (looking at the SharkSSL library > link it looks like it doesn't do DH at all, only RSA key transport). > I've seen PLCs where DHE+RSA leads to handshake times of 10-15s (not > an M3, I just use that as a convenient mental model for an embedded > CPU, this was using an industrial Power SoC), which isn't a good > thing when what you're trying to communicate is an emergency shutdown > command. > > In these situations, crypto comes at about position 77 in the priority > list, with most of the previous ones taken up by "reliability" and > "availability". If you write a spec that in effect mandates a > 15-second delay in communicating commands to a controller, guess what > vendors are going to do?
attacks only get better if the hardware can't do crypto securely now, it certainly won't be able to do it tomorrow (you know, in the "Long Term") it's a waste of time to patch up attacks that are still largely theoretical if you leave a mile wide hole in the fence -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
