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

Groups > comp.lang.forth > #18269

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

Show all headers | View raw

Paul Rubin wrote:

> Bernd Paysan <bernd.paysan@gmx.de> writes:
>> Have a merry christmas!
> 
> The same to you ;-)
> 
>> Which is why a standard on cryptography should be wrapped up in a way
>> that avoids people from making stupid mistakes.
> 
> See, here is the disagreement: as I see it, the NIST AES spec is not a
> standard about "cryptography", it's a standard about a particular
> block cipher, similar to the standard about type 6061 aluminum
> mentioned earlier.

So you are saying that when I'm actually interested in cryptography, I 
can ignore that standard, just as I can ignore 6061 aluminium when I 
plan to build an aircraft?  Today, I would probably build an aircraft 
more out of carbon fiber-based materials, just like Boeing and Airbus 
industries do.

> The standard just says what AES is and gives some test vectors
> for the different modes.  How to use them is not a black art: there
> are textbooks about that, just like there are books about numerical
> analysis, digital signal processing, statistical data mining, or any
> other subject in programming that requires knowledge beyond how to
> shovel bits around and use the "while" statement.  The main "stupid
> mistake" is simply in presuming that those books don't contain
> anything worth reading and tha,t the naive but confident programmer
> can code up the first thing that comes into his head and everything
> will be fine.

Hehe.  Well, for most IT-related people, cryptography is black art, and 
they can't read the books mentioned.  What they need is a nicely wrapped 
up library, and when you are serious about a cryptography standard, you 
should really produce that nicely wrapped up library.

> I've heard this called "ego-oriented programming".  It doesn't work in
> cryptography.

All the really good cryptographers like Bruce Schneier or Dan Bernstein 
have an ego that swallows black holes that accidently come nearby.  They 
aren't naive.  But they still have a big ego.

> Another comparable standard might be the IEEE 754 standard on floating
> point arithmetic.  It was written by numerics experts but it doesn't
> tell you how to actually do numerical integration.  You have to
> consult
> textbooks for that.  IEEE 754 just says how the low level primitives
> should work.  Users generally know better than to expect more than
> that
> from it.  Why should they expect the AES standard to be different?

IEEE 754 is a fairly decent standard when you implement floating point 
functions; you don't have to read other books to implement a sane 
floating point instruction set (or library basics).  It just works.

>> the NIST still hasn't concluded which operation mode is good.
> 
> Again, it's not part of the scope of the standard.  It's just like the
> ANS Forth standard says what the different Forth words do, but doesn't
> way when to use them.

I think we are better here.  ANS Forth is not a tutorial, and it's also 
not a book to teach people how to implement a Forth system, but it is 
fairly close.

>>  And the other cryptographers, neither.
> 
> I don't think there's serious disagreement between cryptographers
> about what the different modes do or when it's ok to use any
> particular one.

These people *are* oppinionated, and they do have different opinions 
about AES.  AFAIK, Dan Bernstein included AES into his NaCl library only 
for the reason that some stubborn people won't buy anything without AES 
in it, and he uses it in counter mode; i.e. just as replacement for his 
stream cipher, which he strongly prefers.

Dan Bernstein is certainly an ego-oriented programmer, and his programs 
are pretty good (though often badly maintained, as they contain "by 
defintion" no bugs ;-).

>>> What black magic?  The thing to do is supply a library that
>>> implements a sensible mode for the application.
>> That's what the NIST should do, as it is their standard.
> 
> By that logic, the IEEE 754 committee should be specifying algorithms
> for numerical integration.  It's just not part of the standard's
> scope.

AES is spelled out "advanced encryption standard".  It's not spelled out 
"block cipher primitive".  I myself wouldn't use a block cipher, and 
I've explained why.  There are more versatile crypto primitives, though 
they are all significantly newer than Rijndael.

>> If everybody does it on his own, we will continue to see the
>> troubles.
> 
> There are some pretty good libraries out there, though I agree it
> would be helpful if they exposed some more straightforwardly usable
> interfaces.  I've supported a few of those myself and have found it's
> best to keep the API as simple as possible, even at some moderate
> performance and storage cost from making the library do extra work.

Yes.

>> Readable keccak is 55 lines.  You can always write it from scratch if
>> you need it, it is so simple.
> 
> The most difficult part of a crypto library is usually a secure random
> number generator.

You mean the secure initialization value for the secure PRNG.  The 
secure PRNG itself is not tricky.  The initialization is.

> It's great if the OS has that as a built-in
> service, but otherwise you have to somehow gather system entropy
> inside your library.

Or ask the user to gather entropy for you.  I remember things like "move 
the mouse pointer" or "type in keys" from the time where /dev/random 
wasn't available.

>> FSE is just a first step.  A NIST contest on symmetric cryptography
>> primitives would be better; they have the most attention.
> 
> eSTREAM was also pretty good.
> 
>> Which is how last year, SSL pretty much collapsed, by having its PKI
>> broken.
> 
> That's a bit of an overstatement, but yeah, TLS would not be done the
> same way today.

I don't think there is an agreement how to fix the PKI.

>> [Enigma] They had employed 40k people at some times for breaking it.
>> I still find it unbelievable that there were no leaks.
> 
> I wonder how many of those 40k people knew actually what was going on.
> Someone translating intercepts would probably not be told where the
> intercepts came from, for example.  Someone sitting in an intercept
> station might not have any idea what was being done with the
> intercepts,
> or how many other people were doing the same thing.  People who knew
> the secret weren't allowed near enemy territory, etc.

I'm sure the Nazis had spies in UK.  If you want to know how they 
treated people of somewhat German origin who would never spy for 
Germany, ask Stephen Pelc.  The story of his father is very interesting.

>>I can accept stubborness, that is very human.
> 
> Yeah, military organizations are unlikely to act on vague rumors, even
> if something like that reached them.
> 
>> Well, a lot of algorithms are significantly faster than AES in
>> software.
> 
> At the time it was developed, AES in software was pretty fast compared
> to the alternatives (RC4 was faster but had known distinguishers). 
> I'm all in favor of doing stuff in hardware when possible.

One of the key things in cryptography is that you should never bet 
yourself on one horse only.  That is, you should have some choice in 
algorithms, and a preferred one, which may fall out of favor if it is 
cracked (and then it should be replaced pretty quickly).

I.e. you should implement more than one primitive in hardware.

>> The GF multiplication in GCM is not sufficiently secure as crypto
>> primitive, which makes me wonder how secure the GCM authentication
>> is.
> 
> I thought GCM has a security proof conditional on AES being secure:
> i.e., there is a theorem that says that if you've got a way to break
> GCM authentication that you can wrap into a subroutine, then you can
> use the
> subroutine to break AES itself.  So if no break against AES exists,
> then
> no break against GCM exists.  Of course if AES is breakable, then AES
> users have a problem regardless of GCM's situation.

Authentication is a bit easier than a standard secure hash - you don't 
have attacks where the sender creates a pair of messages, which have 
both the same signature.  So yes, you can do an authentication with an 
insecure hash, given that it is keyed (i.e. that you can only generate 
the hash when you know the key and the plaintext).

>> AES, which used to be implemented table-driven... This is a known
>> weakness.
> 
> I'd say certain implementations were leaking information other than
> the
> ciphertext.  It's nice if an algorithm mitigates stuff like that, but
> high-security applications will usually want the crypto in hardware
> anyway.

Some hardware had successful attacks, too.

>>>> distinguisher for AES reduced to 7 rounds... 2007.
> 
> Hmm, I may ask around the crypto crowd to find if anyone thinks this
> is a serious concern.

It's at least a low-margin concern.  It would be nice to know how much 
material you need for a distinguisher for 5, 6, resp. 7 rounds, to see 
how that would extrapolate.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

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