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

Groups > comp.lang.forth > #18165

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

Show all headers | View raw

Andrew Haley wrote:

> Paul Rubin <no.email@nospam.invalid> wrote:
>> Bernd Paysan <bernd.paysan@gmx.de> writes:
>>> Yes, but due to that better understanding, crytographers don't
>>> recommend using block ciphers anymore.
> 
> Hmm.  Refeences required.

Paul has already pointed at Dan Bernstein.  However, this goes further: 
Nobody in their right mind are using block ciphers as real block ciphers 
(ECB mode).  You use them with various modes (CBC, CTR, OFB), which turn 
them into something that has similar properties as a stream cipher 
(CTR+OFB are real stream ciphers, CBC is something different).

>> 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.
> 
> The disadvantage of stream ciphers is obvious, though: change one bit
> in the plaintext and you change one bit in the ciphertext.

Yes, this allows to apply forward error correction, and encrypt 
afterwards.  That's the best thing to do on encryption for e.g. a 
wireless network: The attacker gets a partially garbled encrypted 
packet, and can't even reconstruct it without knowing the key - as there 
are many, many ways to decrypt+reconstruct it.  A brute force attack is 
difficult when you don't even know when you have succeeded.

You know that for using a stream cipher, you have to use an IV, and thus 
you always change a lot more than just one bit of the plaintext 
(changing one bit in the IV should give you an entirely different 
keystream).

> Also, if you have known plaintext you have the keystream.

Unless you did a big mistake in your secure PRNG, you only get that part 
of the keystream where you know your plaintext, you can't continue it.  
The key to a secure PRNG is to have at least as much unexposed internal 
state as you have output state.  Funny enough, this is also the way to 
fix Merkle-Dangard ("wide pipe"), and IMHO, that should be applied to 
the primitive for all operations.

Anyways, stream vs. block cipher is a false dichotomy; "sponge function" 
primitives (Keccak) or similar constructs like my Wurstkessel offer a 
third way, which uses the hashing part (diffuse the plaintext with the 
rest of the internal state) to modify the PRNG.  The Keccak team has 
done a thorrough cryptanalysis of the sponge function approach, and it 
has lots of advantages compared to both block and stream ciphers.  E.g. 
you can do en/decryption and authentication in one go, by using the 
residual state of your sponge function as keyed hash.

A sponge function works like that: m=message, a, b=internal states, 
f=sponge function

f(m)={
state: a,b;
f=(a^=m); // output+modification
a,b=sponge(a,b); } // internal permutation

The downside of this is that in encryption mode, an attacker knows a 
part of the internal state, even without knowing the plaintext.  
Therefore, Wurstkessel uses a slightly different approach:

f(m)={
state: a,b;
a^=m; // modification
f=b^m; // output
a,b=sponge(a,b); } // internal permutation

The argument of the sponge function approach is that it shouldn't harm 
the security when half of the internal state is exposed, anyways.  My 
argument is that it is more secure that way, though the lower bound of 
security (under full known-plaintext) is the same.  However, full known 
plaintext is the situation where you don't benefit from cryptography at 
all.

>> 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.
> 
> Eh?  Surely password hashing and digital signatures are essentially
> the same problem: you want a one-way function.

The difference is that for password hashing, you want a slow one-way 
function (slowing down brute force attacks), and for digital signatures, 
you want a fast one-way function.  If it takes 10ms to hash your 
password when you log in, you don't care.  But it's good to know that an 
attacker needs the same 10ms to try one password.

My recommendation is to use passwords only to unlock secure assymmetric 
keys locally, and use pubkey authentication for remote access.  The way 
I do it is as follows: I generate a secure key s, which for Ellyptic 
Curve Cryptography (ECC) is just a trimmed random number.  The secure 
key p is p=s*B, B is the "base" of the curve (a constant), "*" the curve 
multiplication operator.  You now hash your password with 
h=hash(p,password), using your public key as key for the keyed hash, and 
store s^h as encrypted secure key.  To verify if the entered password is 
correct, you check if your decrypted s*B==p.  You can use arbitrary long 
passwords; you can e.g. use an image file as password (or part of the 
password).  Thus an attacker who steals your private keyring also should 
install a key and file access logging rootkit, as a brute force attack 
is slowed down by having to try all files on the system plus the 
passwords in the dictionary (and by hashing the password first, the 
combinations are expensive).

The pubkey authentication with ECC is pretty simple, it doesn't require 
digests and such: when you have two key pairs p1,s1, and p2,s2, 
p1*s2==p2*s1.  So you exchange your pubkeys as ID for the connection, 
and both sides compute the shared secret p1*s2 or p2*s1, and if they 
then can communicate, the communication is authenticated - or one side 
did steal the secret key of the other side.

I've decided to use Wurstkessel for net2o, because I can't have the 
combination of features I want with algorithms that went through the 
scrutinity of e.g. a NIST contest.  However, with Keccak as winner of 
SHA-3, the situation is now different - it has only won the hash 
contest, but it is a general purpose primitive, useful for en/decryption 
and PRNG, and the NIST announcement does encourage to use this primitive 
for other purposes, too.

-- 
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