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

From	Paul Rubin <no.email@nospam.invalid>
Newsgroups	comp.lang.forth
Subject	Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth
Date	2012-12-20 13:56 -0800
Organization	Nightsong/Fort GNOX
Message-ID	<7x7goc5qx3.fsf@ruckus.brouhaha.com> (permalink)
References	(6 earlier) <626ebdde-0470-48f7-bd2e-d121942b2e67@googlegroups.com> <7x38z9i7kq.fsf@ruckus.brouhaha.com> <1567029.DOJmvXz4ur@sunwukong.fritz.box> <7x7godh3sv.fsf@ruckus.brouhaha.com> <3677247.pNypgmlJuf@sunwukong.fritz.box>

Show all headers | View raw

Bernd Paysan <bernd.paysan@gmx.de> writes:
> Yes, but due to that better understanding, crytographers don't recommend 
> using block ciphers anymore.

I think the reason for this is block ciphers have a characteristic
(invertability) that is not needed for message encryption (think of CTR
mode), and which costs performance.  Stream ciphers are attractive
because they're potentially faster.  On the other hand, it seems like
less is understood about their design, and AES implemented in hardware
(such as on modern x86's) is faster than stream ciphers implemented in
software.  AES is still the preferred primitive for high-security
applications AFAIK, the subject of many standards, etc.  

> This is a fragile approach, and people do make mistakes.  You better
> give them some building blocks that are more robust, and require less
> knowledge to be used securely.

That doesn't sound like Forth ;-).  Really, non-knowledgeable
implementers shouldn't be messing with crypto primitives in the first
place.  They should use libraries that do the right thing with the
primitives to supply higher-level interfaces to the application.

> That's not what I said.  The problem of a block cipher is that the key 
> is *constant*.  This same key is used over and over again.  This is the 
> problem.  In a key diffusion scheme (sponge functions like Keccak or 
> Wurstkessel, or stream ciphers), the key is just the initial value; it 
> will not be seen again after the first round.

Certainly not true of all stream ciphers (think of AES-CTR).  And
requiring later message blocks (I think you mean blocks rather than
rounds) to depend on the encryptions of the earlier ones makes the
algorithm harder to parallelize.

> Since we already know about the key reuse issue, we need IVs, and when 
> we have the IVs public, we again have a potential weakness.  

Of course the IV's don't have to be public.  You can use a mode that
doesn't expose them, or even encrypt them with ECB mode.

> So even if there are leaks, they won't leak the original key.  Even if a 
> packet key leaks, it won't allow you to determine the next packet key, 
> due to the hidden internal state of the PRNG mode.

Yeah, I think I understand what you're getting at, and it's worth taking
into consideration in some applications.  But even in those cases I
think it's better to have concrete security analysis than to act on
vague principles.  In high-security applications the answer seems to be
to secure the hardware to prevent such leaks.  As far as I know, this
approach is generally successful (if relatively expensive).  For
example, it's now much harder to crack smart cards than it used to be,
because the hardware designers have learned how to defeat the easier
attacks, including stuff like timing leaks.

> ... MD5 is broken, and SHA-1 is weak, SHA-256 and SHA-512,
> which have the same theoretical flaw, are still considered good...
> For me, a theoretical problem is sufficient to avoid an algorithm, I 
> don't think you should wait for an actual break.

Well, the issue here is you seem to be saying that you know something
that the designers of the non-Keccak SHA-3 finalists somehow didn't
know.  And well, I think they were actually pretty familiar with
existing work and they gained credibility by finding and publishing
breaks against other proposed primitives, so with no disrespect intended
I tend to weight opinions backed by those sorts of concrete results over
opinions backed by vague surmises.  

That said, the real underlying problem is one we both recognize: the
extreme difficulty of any type of rigorous security analysis on
primitives, which is tied to the similarly extreme difficulty of lower
bounds proofs in complexity theory.  So what's left is a black art with
more reliance on "feel-good factors" than is mathematically satisfying.

I'll confess that for this reason I somewhat purposely haven't studied
the mathematical inner workings of crypto primitives very much,
preferring to just use what is already standardized according to its
advertised properties.  (I'm not saying that ignorance is good, but only
that knowledge in this area lower than specialist/professor level
doesn't seem all that useful, so my energy is more productively directed
to other areas while letting specialists supply the primitives).

Protocols used to be the same way, but it's much better now: if someone
proposing a new protocol can also give a security reduction showing that
breaking the protocol is equivalent to breaking the underlying
primitive, anyone else can check the reduction and decide whether the
claim is sound.

>> Keccak (like AES) was selected primarily for performance reasons
> There were two reasons, one was the performance ...  the other was to
> reward the new, completely different approach taken.

I'm surprised if the second was really a reason since I'd have expected
such a process to favor conservatism, and use of a new approach is
typically considered a risk factor.  Are there any publications saying
that the new approach was treated favorably because it was new?

> The latter thinking is good, the further not; if a hardware
> implementation gives a particularly large performance advantage to a
> software implementation, at least password cracking using that hash
> can be accellerated too much by creating dedicated hardware 

I think one of the sha-3 design goals was parallelizability, where
hardware clearly has enormous advantage.  Password hashing shouldn't and
probably didn't figure at all into the design of the primitive, whose
main envisioned use was probably digital signatures.  If you want to
defeat hardware attacks against password hashing, you probably want
scrypt:

  https://tools.ietf.org/html/draft-josefsson-scrypt-kdf-00

More generally one should avoid sending hashed passwords over cleartext
channels or storing unkeyed hashes in databases.  If you have to use
passwords at all, it's better to use protocols like SRP than to send
hashes over the wire.

> My approach is: We must allow some information leakage per round, 
> without making that information leakage a successful attack.  Trying to 
> prevent information leaks through known side-channels is the wrong 
> approach, as you will miss the unknown side-channels.

But you might also allow known leaks while missing unknown leaks. ;-)

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 Howerd <howerdo@yahoo.co.uk> - 2012-11-28 14:31 -0800
  Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth Howerd <howerdo@yahoo.co.uk> - 2012-11-28 14:36 -0800
  Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth Josh Grams <josh@qualdan.com> - 2012-11-30 00:08 +0000
    Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth Howerd <howerdo@yahoo.co.uk> - 2012-11-30 13:56 -0800
      Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth Josh Grams <josh@qualdan.com> - 2012-12-01 16:02 +0000
        Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth Howerd <howerdo@yahoo.co.uk> - 2012-12-01 13:54 -0800
          Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth Josh Grams <josh@qualdan.com> - 2012-12-02 11:26 +0000
  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