[147407] in cryptography@c2.net mail archive
Re: [Cryptography] Crypto Standards v.s. Engineering habits - Was:
daemon@ATHENA.MIT.EDU (Dirk-Willem van Gulik)
Tue Oct 1 13:32:59 2013
X-Original-To: cryptography@metzdowd.com
From: Dirk-Willem van Gulik <dirkx@webweaving.org>
In-Reply-To: <E4C6EE5F-3A46-49F6-84E8-57BD4366CE4D@lrw.com>
Date: Tue, 1 Oct 2013 18:27:54 +0200
To: Jerry Leichter <leichter@lrw.com>
Cc: Christoph Anton Mitterer <calestyo@scientia.net>, cryptography@metzdowd.com
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
--===============5551739161519239928==
Content-Type: multipart/signed; boundary="Apple-Mail=_A137049B-A4CA-49BE-94F9-2B370FE9897D"; protocol="application/pgp-signature"; micalg=pgp-sha1
--Apple-Mail=_A137049B-A4CA-49BE-94F9-2B370FE9897D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=windows-1252
Op 1 okt. 2013, om 17:59 heeft Jerry Leichter <leichter@lrw.com> het =
volgende geschreven:
> On Oct 1, 2013, at 3:29 AM, Dirk-Willem van Gulik =
<dirkx@webweaving.org> wrote:
>> ...I do note that in crypto (possibly driven by the perceived expense =
of too many bits) we tend to very carefully observe the various bit =
lengths found in 800-78-3, 800-131A , etc etc. And rarely go much beyond =
it*.
>>=20
>> While in a lot of other fields - it is very common for 'run of the =
mill' constructions; such as when calculating a floor, wooden support =
beam, a joist, to take the various standards and liberally apply safety =
factors. A factor 10 or 20x too strong is quite common *especially* in =
'consumer' constructions=85. =20
> It's clear what "10x stronger than needed" means for a support beam: =
We're pretty good at modeling the forces on a beam and we know how =
strong beams of given sizes are. =20
Actually - do we ? I picked this example as it is one of those where =
this 'we know' falls apart on closer examination. Wood varies a lot; and =
our ratings are very rough. We drill holes through it; use hugely =
varying ways to glue/weld/etc. And we liberally apply safety factors =
everywhere; and a lot of 'otherwise it does not feel right' throughout. =
And in all fairness - while you can get a bunch of engineers to agree =
that 'it is strong enough' - they'd argue endlessly and have 'it =
depends' sort of answers when you ask them "how strong is it 'really'" ?
> Oh, if you're talking brute force, sure, 129 bits takes twice as long =
as 128 bits. =20
...
> If, on the other hand, you're talking analytic attacks, there's no way =
to know ahead of time what matters. =20
So I think you are hitting the crux of the matter - the material, like =
most, we work with, is not that easy to gauge. But then when we consider =
your example of DES:
> The ultimate example of this occurred back when brute force attacks =
against DES, at 56 bits, were clearly on the horizon - so people =
proposed throwing away the key schedule and making the key the full =
expanded schedule of 448 bits, or whatever it came to. Many times more =
secure - except then differential cryptography was (re-)discovered and =
it turned out that 448-bit DES was no stronger than 56-bit DES.
with hindsight we can conclude that despite all this - despite all the =
various instutitions and interests conspiring, fighting and =
collaborating roughly yielded us a fair level of safety for a fair =
number of years - and that is roughly what we got.=20
Sure - that relied on 'odd' things; like the s-boxes getting =
strengthened behind the scenes, the EFF stressing that a hardware device =
was 'now' cheap enough. But by and large - these where more or less done =
'on time'.=20
So I think we roughly got the minimum about right with DES.=20
The thing which facinates/strikes me as odd - is that that is then =
exactly what we all implemented. Not more. Not less. No safety; no =
nothing. Just a bit of hand waving to how complex it all is; how hard it =
is to predict; so we listen to NIST* et.al. and that is it then.
*Despite* the fact that, as you so eloquently argue, the material we =
work with is notoriously unpredictable, finnicky and has many an =
uncontrolled unknown.
And any failures or issues come back to haunt us, not NIST et.al.
> There are three places I can think of where the notion of "adding a =
safety factor" makes sense today; perhaps someone can add to the list, =
but I doubt it will grow significantly longer:
>=20
> 1. Adding a bit to the key size when that key size is small enough;
> 2. Using multiple encryption with different mechanisms and =
independent keys;
> 3. Adding rounds to a round-based symmetric encryptor of the design =
we currently use pretty universally (multiple S and P transforms with =
some keying information mixed in per round, repeated for multiple =
rounds). In a good cipher designed according to our best practices =
today, the best attacks we know of extend to some number of rounds and =
then just die - i.e., after some number of rounds they do no better than =
brute force. Adding a few more beyond that makes sense. But ... if you =
think adding many more beyond that makes sense, you're into tin-foil hat =
territory. We understand what certain attacks look like and we =
understand how they (fail to) extend beyond some number of rounds - but =
the next attack down the pike, about which we have no theory, might not =
be sensitive to the number of rounds at all.
Agreed - and perhaps develop some routine practices around which way you =
layer; i.e. what is best wrapped inside which; and where do you (avoid) =
padding; or get the most out of IVs.
=20
> These arguments apply to some other primitives as well, particularly =
hash functions. They *don't* apply to asymmetric cryptography, except =
perhaps for case 2 above - though it may not be so easy to apply. For =
asymmetric crypto, the attacks are all algorithmic and mathematical in =
nature, and the game is different.
Very good point (I did not consider the PKI's at all when I wrote =
above.)
Thanks,
Dw
*: s/NIST/your local applicable standards body or politically correct =
regulator/g.
--Apple-Mail=_A137049B-A4CA-49BE-94F9-2B370FE9897D
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=signature.asc
Content-Type: application/pgp-signature;
name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.20 (Darwin)
Comment: This message is encrypted and/or signed with PGP (gnu-pg, gpg). Contact dirkx@webweaving.org if you cannot read it.
iQCVAwUBUkr4GjGmPZbsFAuBAQIiZQP/cwLFrwOlE+2oMeO65mY3UGchGyMpJZLG
31I9WuwTk4CWST3SG0McoxPbidV2pWOcj92SRh5PaWNAlcw9wSSCFZLMT8RRXJhA
ikUkj6bJyOmhDmjiqHDgVlNUjzQR5xjNR3bvbYBXm/4HU/6fYHKPflmUbcWVK+d4
mfkD6SpVVTM=
=1pQa
-----END PGP SIGNATURE-----
--Apple-Mail=_A137049B-A4CA-49BE-94F9-2B370FE9897D--
--===============5551739161519239928==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
--===============5551739161519239928==--
