Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #18283

Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth

Show all headers | View raw

Bernd Paysan <bernd.paysan@gmx.de> writes:
>> It's partly a matter of the kinds of questions you'll have to answer
>> if something goes wrong.
> That's the sort of thinking I don't like.  I know that many people refer 
> to authority and say "It wasn't my fault, I just covered my ass^W^W^W 
> followed common bad^Wbest practise!"

It's perfectly sound logic if you consider "questions you'll have to
answer" as affecting the amount of financial liability and other
business impact your company may find itself stuck with.  Imagine you
convince yourself that XYZ is twice as good as AES, i.e. you figure that
XYZ has 0.5x AES's probability of catastrophic failure.  If AES fails,
you get to use the CYA defense and the failure costs you M dollars.  If
XYZ fails, you have to come up with some other story and it costs N
dollars.  So if you expect N to be larger than M*2, then XYZ is a bad
bet even though it's "better" than AES.  It's just math.

Actually of course there's a much more compelling reason to follow
existing practices in crypto, which is that your stuff then is able to
interoperate with everyone else's.  Crypto is (usually) about
communication, after all.

> If your algorithm is broken, whatever authority there was, you need 
> another one, and you need it *now*

Only in the movies ;-).  Any AES break causing that much disruption
would probably affect everything else too, so having a backup algorithm
won't help ;-).

Reality: the payment card industry did a multi-year transition away from
single-DES that got seriously underway around 2004.  Remember that the
EFF built a hardware DES cracker in 1999, and AES was standardized in
2002.  Am I saying they switched from DES to AES in the mid-2000's?
Nope, AES was too new then.  They stayed with 3DES as a more
conservative choice while AES built up a track record.  I don't know if
they use AES now.

Single DES was of course way more broken even at that time than anything
we can currently foresee ever happening to AES, and while there was some
urgency to the transition (it was compared to a "Y2K bug" within the
industry) there wasn't a huge panic, and I didn't hear of any reported
decryption of actual traffic by attackers cryptanalyzing DES.  (IIRC the
way it was set up, you'd have to break a DES key for each transaction
stream or maybe even each transaction, so it wouldn't have been worth a
whole lot.  It wasn't like there was one DES key that controlled the
whole system.  But still... .)

> (which means it can not be a complicated update path, and especially

Heh, they had to replace 1e7's of credit card terminals all over the
world, since the older equipment tended to not have upgradeable firmware
(the new stuff did) in addition to backend changes.  Again this wasn't
seen as a panic or disaster, but just as something that had to get done
within a reasonable timeframe (measured in years).  It was pretty well
planned, and lots of crufty processes got modernized along the way.  I
guess it was pretty profitable for the industry since they got to sell
all that new stuff.

> And you don't want the end user to choose the algorithm. ... The end
> user is the one with the least amount of knowledge to do so.
> The easiest way for a protocol is to have capability masks. 

Really I doubt that either the financial industry or the military (the
biggest and most serious crypto users) do anything like that.

> [DJB's] claim was that a quantum computer with enough bits would break
> his [SHA-3 submission] ;-).

For symmetric algorithms I don't think anyone sees anything better than
the generic 2**(N/2) quantum search (Grover's algorithm), but for
public-key, the situation is more complicated and I know that DJB has
been researching it.  So he's probably been thinking about quantum
attacks a lot, and that spilled over to his SHA-3 stuff ;-).

> "Accepted best practise" is a buzzword for people mindlessly following 
> the herd.  The problem if you don't know how to evaluate a method 
> yourself, you *also* don't know how to delegate.

what??  Most people delegate medical stuff to their doctor, airplane
flying to the airline pilot, etc.  And the folks who participated in
those NIST competitions are pretty sharp (look at how much cryptanalysis
they've done), as are the NIST guys themselves.  Who am I to say my
judgment is better than theirs?  DJB was critical of NIST because of
cache timing attacks on AES, but even he hasn't had any complaints AFAIK
about the security of AES as a pure cipher.  DJB's Poly1305 MAC uses AES
although I don't know if he's still using it.

> a NIST contest ... The choice however is not made by the really
> acknowledged experts in the field.

Meh, the entries that get up to the finalist level are all developed by
experts.  The NIST guys are not idiots either (they come to conferences
and give presentations and you can talk to them).  Come to think of it,
John Kelsey (co-designer of one of the AES finalists) works at NIST now.

> Bruce Schneier... was fine with Keccak, probably because that was the
> only entry that *did* advance the state of the art.

That thing you posted was kind of interesting, that said they wanted to
keep SHA2 and Keccak standardized at the same time, so they'd have a
fallback if something went wrong with either one.  Bruce argued rather
voceferously against doing something like that when people suggested
standardizing multiple AES candidates.  But I think the security of hash
functions is even more mysterious than that of block ciphers, mostly
because of the absence of secrets in the operation of a hash function.

> I however like the approach of eSTREAM, having finalists, but no
> winners.

I don't know if that was the intended outcome, or if they just found
themselves unable to pick something.

> What you really need as "standard" for the people who "follow best 
> practice" is a nicely wrapped up crypto-suite. 

There are a bunch of standards like PKCS, ANS X9, and so on; and there
are libraries that implement those standards.

> Something e.g. Dan Bernstein is aming at with NaCl. 

I've written a few things like that too, though less sophisticated than
DJB's.

> Since that however is not blessed by sprinkling holy NIST water on it,
> it won't be used by those people who need it most.

I don't think there's a NIST standard for any public-key methods at the
moment, though I haven't been following this stuff in recent years.
There is IEEE 1363 and the different RSA PKCS documents.  Certainly any
general purpose library should include the modes needed to interoperate
with the stuff that's out there.  I just can't think of many instances
where non-specialists should be messing with raw crypto primitives.

> Hm.  One of the typical case where bad entropy has caused real
> security problems are small routers and access points. ...  They
> should rather gather the entropy during that setup, e.g. by
> ... precisely measuring the timing of the received packets
> (acknowledges and such).

That sounds attackable by someone externally controlling packet timings.
Really, anything with crypto in it should have a hardware RNG if at all
possible.

> Another possibility is to initialize the device during manufacturing, 

Yes, that's how it's done with cheap smart cards and older payment
terminals.  It's more complicated than it sounds, because they have to
take elaborate safeguards against keys leaking during initialization,
e.g. do the initialization process in an expensive shielded room.
Fancier smart cards have on-chip RNG's.

>> AES attack affecting AES-256 (something encroaching on AES-128 is
>> easier to imagine)>
> Really?  AES-256 is generally weaker than AES-128 

To clarify: the idea is that you want 128 bits of security but based on
new attacks, you might have a concern that AES-128 is not really
providing that.  Switching to AES-256 should take care of this problem,
of supplying the 128 bits that you wanted, with room to spare.  It might
indeed not provide 256 bits of security, but that's kind of limited in
usefulness anyway, given the 128-bit block size brings codebook attacks
into play long before 256 bits of keyspace means anything.

> BluRay people were pretty proud for using AES: Now all these geeks had 
> to attack AES for breaking the encryption... and the geeks didn't.  They 
> found an easier way in.

Bluray has fancier defenses than that: they can put new schemes onto the
actual discs, so even if you break the old scheme you can only decrypt
the old discs until you break the new scheme.  Yeah though, it's a hard
problem, when the attacker has control of the hardware.

>>> Some hardware had successful attacks, too.

>> tamper-reactive packaging, EM shielding, physical security around
>> the equipment, etc.
> And that was by far the least successful strategy.

I'm thinking of the stuff in the payment industry: the crypto module is
a rack-mount box that's part of the server stack, surrounded by the
usual access controls and physical security that you find in financial
data centers (which isn't necessarily all that great, though I never
visited one).  I've never heard of deployed instances of this stuff
getting attacked, which doesn't mean it has never happened.  But it's
not like buying a Blu-ray player and hacking it at home.
>
>>  Really though, cryptanalysis of cipher primitives is a generally
>> less likely source of security failures in real systems.  
> Yes, because that's the parts around a crypto system that wasn't 
> reviewed carefully, and the attacker always takes the easiest way in.

Meh, it seems to me that if all the attacker has is pure cryptanalysis
of primitives to use against your traffic, you can stop him with 5 cents
worth of computing resources even if he has the resources of a national
government.  The whole point of all these crypto conferences and new
designs is to let people do that with 3 cents instead of 5 cents (i.e.
make algorithms faster etc.).  And the cryptanalysis side tries to stop
the 3 cent designs and make them spend 4 cents.  If you're willing to
spend, say, 10 cents, there is not much anybody can do ;-).

Back to comp.lang.forth | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth Paul Rubin <no.email@nospam.invalid> - 2012-12-12 14:52 -0800
  Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth Howerd <howerdo@yahoo.co.uk> - 2012-12-12 23:47 -0800
    Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth Paul Rubin <no.email@nospam.invalid> - 2012-12-13 00:38 -0800
      Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth Howerd <howerdo@yahoo.co.uk> - 2012-12-13 20:17 -0800
        Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth Paul Rubin <no.email@nospam.invalid> - 2012-12-13 20:25 -0800
          Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth Howerd <howerdo@yahoo.co.uk> - 2012-12-13 20:53 -0800
            Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth Paul Rubin <no.email@nospam.invalid> - 2012-12-13 21:16 -0800
              Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth Howerd <howerdo@yahoo.co.uk> - 2012-12-14 03:43 -0800
                Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-12-14 12:15 -0600
                Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth Paul Rubin <no.email@nospam.invalid> - 2012-12-20 00:21 -0800
            Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-12-14 04:45 -0600
              Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth Howerd <howerdo@yahoo.co.uk> - 2012-12-14 03:33 -0800
                Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-12-14 12:20 -0600
                Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth Paul Rubin <no.email@nospam.invalid> - 2012-12-14 10:28 -0800
                Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-12-14 12:39 -0600
          Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth Bernd Paysan <bernd.paysan@gmx.de> - 2012-12-15 01:47 +0100
            Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth Paul Rubin <no.email@nospam.invalid> - 2012-12-19 18:10 -0800
              Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth Paul Rubin <no.email@nospam.invalid> - 2012-12-19 19:53 -0800
              Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth Bernd Paysan <bernd.paysan@gmx.de> - 2012-12-20 14:44 +0100
                Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth Bernd Paysan <bernd.paysan@gmx.de> - 2012-12-20 19:28 +0100
                Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth Paul Rubin <no.email@nospam.invalid> - 2012-12-20 13:56 -0800
                Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth Bernd Paysan <bernd.paysan@gmx.de> - 2012-12-21 01:41 +0100
                Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-12-21 03:58 -0600
                Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth Paul Rubin <no.email@nospam.invalid> - 2012-12-21 02:20 -0800
                Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-12-21 06:46 -0600
                Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth Bernd Paysan <bernd.paysan@gmx.de> - 2012-12-21 15:34 +0100
                Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-12-21 08:40 -0600
                Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth Bernd Paysan <bernd.paysan@gmx.de> - 2012-12-22 03:36 +0100
                Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth Paul Rubin <no.email@nospam.invalid> - 2012-12-21 20:07 -0800
                Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth Bernd Paysan <bernd.paysan@gmx.de> - 2012-12-23 02:37 +0100
                Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth Paul Rubin <no.email@nospam.invalid> - 2012-12-22 19:24 -0800
                Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth Bernd Paysan <bernd.paysan@gmx.de> - 2012-12-23 15:52 +0100
                Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth Paul Rubin <no.email@nospam.invalid> - 2012-12-23 17:52 -0800
                Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-12-24 03:57 -0600
                Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth Bernd Paysan <bernd.paysan@gmx.de> - 2012-12-24 16:20 +0100
                Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth Paul Rubin <no.email@nospam.invalid> - 2012-12-24 15:36 -0800
                Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth Bernd Paysan <bernd.paysan@gmx.de> - 2012-12-25 02:52 +0100
                Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth Paul Rubin <no.email@nospam.invalid> - 2012-12-24 21:51 -0800
                Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth Bernd Paysan <bernd.paysan@gmx.de> - 2012-12-25 20:56 +0100
                Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth Paul Rubin <no.email@nospam.invalid> - 2012-12-26 01:08 -0800
                Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth Bernd Paysan <bernd.paysan@gmx.de> - 2012-12-26 16:02 +0100
                Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth David Thompson <dave.thompson2@verizon.net> - 2012-12-31 02:48 -0500
                Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth kenney@cix.compulink.co.uk - 2012-12-24 03:20 -0600
                Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-12-22 03:24 -0600
                Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth Bernd Paysan <bernd.paysan@gmx.de> - 2012-12-23 01:24 +0100
                Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-12-23 04:59 -0600
                Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth Bernd Paysan <bernd.paysan@gmx.de> - 2012-12-23 17:32 +0100
                Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-12-23 11:28 -0600
                Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth Bernd Paysan <bernd.paysan@gmx.de> - 2012-12-24 00:30 +0100

csiph-web