Re: [Cfrg] [TLS] 3DES diediedie

[Derek Atkins <[e-mail]>]

Hi,

Stephen Farrell <[e-mail]> writes:

> Hi Derek,
>
> On 06/09/16 21:44, Derek Atkins wrote:
>> I'm afraid I have to disagree here.  What's it's done is pushed
>> yesterday's computation capabilities into smaller and smaller devices,
>> lower and lower on the food chain.  C.f. my previous email about a light
>> bulb.  Cost is definitely a concern, as well as power and performance.
>
> I think that's true but not the entire story.
>
> Another part of the trade off is that any device that
> connects to the Internet and runs s/w is potentially
> vulnerable and usable to attack the network.
>
> So we're not only talking about security/crypto to
> protect someone's choice of what colour a bulb appears,
> but rather we're very often talking about the protection
> of a small computer on the network, and of the security
> of the network as a whole.

I agree completely, which is why I believe that "AES is the one true
cipher that everything must use" is, IMHO, a Bad Idea (TM).  As Peter
said in another email (thank you, Peter, for the GREAT writeup!!!),
while we do want better crypto, what's more important is MORE crypto.
We want more devices to use crypto, and if there are devices where even
AES can't be used (for whatever reason) we should find reasonable,
lower-"cost" alternatives.

> That last I think argues strongly for support for
> sufficiently good crypto everywhere. And I'm not sure
> what sufficiently good options exist that are notably
> lighter weight than AES. (And if one does support good
> crypto then there seems less reason to use less good
> crypto for some functions.)

I know you're anti Simon/Speck, but there are a good dozen other
potential symmetric LWC candidates, based on ISO specification interest
and the NIST LWC workshop(s).

> Note that I'm arguing against weaker crypto or crypto
> of unknown or possibly-problematic provenance here. So
> I'm not arguing for HW-AES-everywhere. But it is also
> true that AES-everywhere would avoid this significant
> problem.

What's your definition of "weaker" crypto?

I'd argue that there are definitely cases where a shorter block size is
just fine, even if it's easier to attack.  For example, if I have a
64-bit block size and my messages are always only a single bit
(e.g. "door open" or "door closed"), does it matter that it's easier to
attack than a 128-bit block size?

Context is extremely important.  Obviously 64-bit blocks would be bad
for some things, but might be "just fine" for others.  If we do say "no
64-bit blocks" then we get sensor manufacturers that will say "fine,
security is too expensive so I just wont put it in".

The Perfect is the enemy of the Good Enough.

> That said, I do realise that this is not a winning
> argument as people will develop feature-rich devices
> with crap security and there's no device-police to stop
> them, but we (as in cfrg) should really also bear in
> mind that any weaker crypto anywhere has significant
> downsides as many devices really do need what we currently
> consider strong crypto because they connect to the
> Internet and may not get any updated s/w for quite some
> time.

True, this will happen too.  From where I sit I'd rather give people
better tools that might not reach our "perfect" security guidelines, but
are cheap enough that the manufacturers will implement it instead of XOR
(against a static "key").

> So... it's tricky - I think we know what's right but we
> also know that that's not what "the market" is going
> to produce;-)

I think this is the main issue -- different markets have different
needs.  And until you're living on an 8051 or MSP430 you really don't
understand how constrained you can be.

> S.

-derek

-- 
       Derek Atkins                 617-623-3745
       [e-mail]             www.ihtfp.com
       Computer and Internet Security Consultant