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

Groups > comp.lang.forth > #19512

Re: OT: HTTPS cracked

Show all headers | View raw

Paul Rubin wrote:
> AES claims to be a pseudorandom permutation, which means it's broken
> if you've got a way to distinguish a single instance (using a random
> key)
> from a true random permutation.  The security of all the standard and
> not-so-standard modes of operation can be deduced from this property.
> Even small families of outright weak keys (like DES's) wouldn't
> directly
> affect AES's security claim.  It would be interesting and somewhat
> disconcerting if they were found, of course.

Related key attacks are indeed indirect attacks, but there are often 
cases where you have poor entropy in the system that generates the keys.  
As Schneier puts it, cryptosystems are rarely directly broken, but most 
often circumvented.  This TLS attack here is just another case.

In any case, if you have a related key problem, you must choose your 
keys so that they are unrelated.  This reduces the possible space to 
choose keys from, and thus also reduces the strength of the algorithm.  
Enough bits keep you safe, so this is not necessarily a practical 
problem - you don't need that many different keys in your lifetime, so 
using a good secure random number generator is sufficient to give you 
all the unrelated keys you need.

The current state of this related-key attack is that you can crack one 
out of every 2^35 (randomly chosen?) keys with a complexity of 2^96.  
The other keys are considerably harder.

> DJB's paper about NaCL is pretty recent and gives a much higher
> security
> figure than 2**100 for AES-256.  It might have said 2**240 or
> something like that; I don't have it in front of me.

The whole thing about AES is that "it somehow works if a number of 
conditions is met".  The broad claims of Rijndael weren't met.  Looking 
at the other AES finalists makes it hard to choose something better, 
though ;-).

If you have unrelated keys, you can only deduce two bits of the keys 
with practical attacks.  You can deduce some more with impractical 
attacks.

The general attitude at cryptography is that any algorithm that doesn't 
meet its claims is considered broken, even if the attacks are not (yet) 
practicable.  This is a sound attitude, though we certainly have 
examples where first successes didn't lead to more damage (like on 
SHA-1, which did not completely break down, while MD5 did).

Therefore, if you already use that algorithm, you can continue to use it 
as long as the attacks are not practicable, but you need to add another 
option.  That's what NIST did with starting a new round on hashes, but 
they only started it when MD5 was too weak to be used any longer, and 
therefore, the concerns were really serious.

But if you don't use that algorithm, then it's off limits.  It's 
considered broken.  It's not a sound design decision to use an algorithm 
with known weaknesses, just as it is not a sound design decision to use 
an algorithm that hasn't gone through a lot or review.  It has to go 
through this unscratched, that's the whole point of it.

IMHO, the whole approach of block ciphers is problematic.  You want a 
pseudo-random function that is bijective, i.e. it already violates one 
of the tests for randomness by design: It does not meet the birthday 
paradox, and it can not.  That by itself is not such a big problem, but 
one of the reasons why you should not easily use AES as primitive for a 
known-key hash is that you can always work your way backwards, it's not 
a one-way function.  That scares me, because if I can work my way 
backwards through the Keccak or Wurstkessel permutation/transformation, 
I know that all the other claims fall apart.  But that's because these 
functions have been deliberately designed for hashes, and that's under 
"known key" conditions, and then use this property to prove that all 
other modes of operations are secure, 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 | Unroll thread

Thread

OT: HTTPS cracked Mark Wills <forthfreak@gmail.com> - 2013-02-05 02:59 -0800
  Re: OT: HTTPS cracked Mark Wills <forthfreak@gmail.com> - 2013-02-05 03:01 -0800
    Re: OT: HTTPS cracked Alex McDonald <blog@rivadpm.com> - 2013-02-05 06:29 -0800
      Re: OT: HTTPS cracked Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-05 18:16 +0100
        Re: OT: HTTPS cracked Paul Rubin <no.email@nospam.invalid> - 2013-02-05 09:53 -0800
          Re: OT: HTTPS cracked Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-05 22:43 +0100
            Re: OT: HTTPS cracked Paul Rubin <no.email@nospam.invalid> - 2013-02-06 05:00 -0800
              Re: OT: HTTPS cracked Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-06 19:21 +0100
                Re: OT: HTTPS cracked Paul Rubin <no.email@nospam.invalid> - 2013-02-08 01:06 -0800
                Re: OT: HTTPS cracked Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-08 17:23 +0100
                Re: OT: HTTPS cracked Paul Rubin <no.email@nospam.invalid> - 2013-02-09 20:04 -0800
                Re: OT: HTTPS cracked Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-11 02:56 +0100
      Re: OT: HTTPS cracked the_gavino_himself <visphatesjava@gmail.com> - 2013-02-08 19:27 -0800

csiph-web