On 29/09/13 16:01 PM, Jerry Leichter wrote:
...e.g., according to Wikipedia, BATON is a block cipher with a key length of
320 bits (160 of them checksum bits - I'd guess that this is an overt way for
NSA to control who can use stolen equipment, as it will presumably refuse to
operate at all with an invalid key). ...
I'm not really understanding the need for checksums on keys. I can sort
of see the battlefield requirement that comms equipment that is stolen
can't then be utilized in either a direct sense (listening in) or
re-sold to some other theater.
But it still doesn't quite work. It seems antithetical to NSA's
obsession with security at Suite A levels, if they are worried about the
gear being snatched, they shouldn't have secret algorithms in them at all.
Using checksums also doesn't make sense, as once the checksum algorithm
is recovered, the protection is dead. I would have thought a HMAC
approach would be better, but this then brings in the need for a
centralised key distro approach. Ok, so that is typically how
battlefield codes work -- one set for everyone -- but I would have
thought they'd have moved on from the delivery SPOF by now.
Cryptographic challenge: If you have a sealed, tamper-proof box that implements, say,
BATON, you can easily have it refuse to work if the key presented doesn't checksum
correctly. In fact, you'd likely have it destroy itself if presented with too many
invalid keys. NSA has always been really big about using such sealed modules for their
own algorithms. (The FIPS specs were clearly drafted by people who think in these terms.
If you're looking at them while trying to get software certified, many of the provisions
look very peculiar. OK, no one expects your software to be potted in epoxy ("opaque
in the ultraviolet" - or was it infrared?); but they do expect various kinds of
isolation that just affect the blocks on a picture of your software's implementation;
they have no meaningful effect on security, which unlike hardware can't enforce any
boundaries between the blocks.)
Anyway, this approach obviously depends on the ability of the hardware to
resist attacks. Can one design an algorithm which is inherently secure against
such attacks? For example, can one design an algorithm that's strong when used
with valid keys but either outright fails (e.g., produces indexes into
something like S-boxes that are out of range) or is easily invertible if used
with invalid keys (e.g., has a key schedule that with invalid keys produces all
0's after a certain small number of rounds)? You'd need something akin to
asymmetric cryptography to prevent anyone from reverse-engineering the checksum
algorithm from the encryption algorithm, but I know of no fundamental reason
why that couldn't be done.
It also seems a little overdone to do that in the algorithm. Why not
implement a kill switch with a separate parallel system? If one is
designing the hardware, then one has control over these things.
I guess then I really don't understand the threat they are trying to
address here.
Any comments from the wider audience?
iang
_______________________________________________
The cryptography mailing list
[email protected]
http://www.metzdowd.com/mailman/listinfo/cryptography
