
Why 256 bit keys are large enough - mef
http://security.stackexchange.com/questions/25375/why-not-use-larger-cipher-keys
======
mjs
Doesn't that Schneier quote only apply to symmetric algorithms (e.g. AES)? I
thought asymmetric algorithms (e.g. public/key systems like RSA, as in the
original question) have completely different characteristics and rules.

"NIST key management guidelines further suggest that 15360-bit RSA keys are
equivalent in strength to 256-bit symmetric keys."

[http://en.wikipedia.org/wiki/Key_size#Asymmetric_algorithm_k...](http://en.wikipedia.org/wiki/Key_size#Asymmetric_algorithm_key_lengths)

~~~
iwwr
Using elliptic-curve cryptosystems you may be able to reduce PK key sizes to
near symmetric crypto lengths (within a factor of 2-4).

<http://www.nsa.gov/business/programs/elliptic_curve.shtml>

But remember that before we build our Dyson sphere, we may get quantum
computers, which makes our bruteforcing polynomial rather than exponential.
Cryptsystems based on discrete log, EC discrete log or prime factorization
(pretty much all existing crypto-infrastructure) are vulnerable.

More on this <http://en.wikipedia.org/wiki/Post-quantum_cryptography>

~~~
Lagged2Death
_But remember that before we build our Dyson sphere, we may get quantum
computers..._

Does quantum computing somehow get around the fundamental energy requirements?

~~~
iwwr
For symmetric cryptosystems search difficulty is halved (a 256 bit AES key
under a quantum bruteforce becomes as 'hard' as a 128 bit key under
conventional bruteforce).

For asymmetric systems, search is reduced to polynomial (if using the discrete
log, EC discrete log or prime factorization).

~~~
jacquesm
Doesn't halving the search difficulty mean dropping 1 bit from the key length?
So 256->255 rather than 256->128?

~~~
scott_weber
The numbers are correct, but it was written in an odd way. Grovers algorithm
gives a speedup of sqrt(n), so the exponent gets halved.

------
bajsejohannes
This a very good explaination of why 256 bits is enough against _a brute force
attack_. The goal of breaking cryptographic systems is of course not brute
force, but to reduce the actual key space you have to search. This is
frequently measured in how many redundant bits you can shave off. So for AES,
we might find in the future that 256 bits isn't enough after all.

~~~
p4bl0
Actual implementations of 256 bits AES are already breakable using side-
channel attacks.

~~~
chii
so if that key size is increased, would these side channel attacks be either
mitigated, or made impractical?

~~~
p4bl0
No that's not the way to go for countermeasures against side-channel attacks
(breaking 4096 bits key in asymmetric crypto is also doable using side-channel
attacks, even in the cloud [1]). Since it is a physical attack rather than a
mathematical one, the countermeasures are at the physical level too: the idea
is to make the cryptosystem leak less information through channel such as
power consumption, computation or memory access time, electromagnetic
radiation… Currently most of these countermeasures are at hardware level.

[1] <https://news.ycombinator.com/item?id=4865516>

Edit: forgot to add reference link.

------
ars
One reason for extra large keys is for headroom in case of partial breakage.

Usually when a cipher is broken, they don't break it fully, but rather reduce
the keyspace. By making your starting keyspace even larger you make even a
broken cypher secure (up to a point).

~~~
VLM
You are correct but its also extremely educational to graph the decrease over
time, for various cryptosystems both real/pro and "roll your own".

The difference between a professionally designed algo and a "roll your own"
algo is the roll your own is usually extremely brittle and shatters to nothing
in one discovery vs a professionally designed algo usually has multiple
generations of grad students chip away maybe an average of 10 bits per decade
as newer forms of analysis are slowly invented and/or declassified.

If you roll your own, its at least several orders of magnitude more likely to
break than a pro algo, and when it does, unlike the pro algo, it'll almost
certainly snap all the way at once, so using a large keyspace just means more
of an epic fail and wasted processor power. On the other hand if you use a
real algo, then a loss of 20 bits per decade or whatever average really does
help, so crank the keyspace to the max. So I'd have to disagree with you
there, if you're using a broken (homemade?) algo don't bother with more than 8
bits or so, any more is just wasting processor time, homemade is only useful
for casual obfuscation. If you're using a real algo, then, and only then,
larger keyspace actually will save you over the long run...

------
UnoriginalGuy
I wish I knew more about encryption. Unfortunately it isn't a very accessible
area, even if you have a degree in CS you aren't really qualified to even
touch the stuff, you need a maths degree at the very least.

Plus every time anyone brings up the subject the answer is always the same:
"If you roll your own crypto you're an idiot." Which is not very encouraging.
Likely why crypto' libraries are so antiquated and terrible.

~~~
ars
By far the simplest encryption to understand is the factorization problem.

If you have two prime number it's trivial to multiply them and get the result.
Or if you have the result and one prime number, it's also trivial to divide
and get the second prime number. But if you have that result, figuring out
which two prime numbers divide it requires you to check every single one of
them - which takes much longer.

Now imagine your password is one of the prime numbers, and your secret message
is converted to a different prime number. Multiply your password with the
secret message and you have your result. That's the encrypted message.

Without knowing what the password was, there is no feasible way to figure out
what the message was - you would have to divide by every prime number looking
for another prime number that evenly divides into the encrypted message.
(Technically once you do that you don't know if that prime number was the
message or the password.)

This is the core of encryption - the trouble is the side-details can mess you
up, and they are really not obvious. For example: How do you securely convert
a message into a prime number? Or a password into a prime number?

You can't use the entire message as one enormous prime number, that's not
feasible, so you have to break it up. How do you do that properly, without
leaking information?

There are other issues with the math (I'm not familiar enough with encryption
to even know what they are, but they are things like certain primes have
patterns that make themself obvious in the result). See
<http://en.wikipedia.org/wiki/Semiprime> for some primes patterns to avoid.

Then there are issues with the implementation - if you are on a multi user
system (or a remote system) you want to make sure people can't figure out the
password by watching which system resources you use, or how long things take
you.

And then issues with the algorithm: If you encrypt two documents with the same
password it can be possible to compare them and figure out what you used. So
you want to add some randomization to the password to make that impossible.
But getting good random numbers isn't always easy. And you have to store that
random number in the message so it can be reversed - but watch out that you
didn't do that in a way that negates the advantage of the random number.

~~~
gjm11
This system is (almost) just a variant of the one-time pad.

 _One-time pad_ : before Alice and Bob need to send secret messages to one
another, they generate a large blob of random bits and each take one copy of
it. They keep these bits very secret. When one needs to send an N-bit message
to the other, s/he takes the next N bits of the blob and XORs them with the
message. This is trivial to do and provably impossible to break -- except that
making and sharing and keeping all that key data (the big blob of bits) is
really inconvenient and easy to get wrong.

So, anyway, your system has the same weaknesses as any other one-time pad: you
need new key data for every message you send, which means you have to make a
lot of key data, share it with your partner in crime, and remember it for a
long time, all without leaking any of it.

It's not _quite_ the same as a one-time pad. You can get by with fewer bits of
key than bits of message, provided there's still "enough" key. On the other
hand, "enough" is quite a lot, much more than the key length of a typical
symmetric cryptosystem like AES.

Anyway, I don't think this counts as "by far the simplest encryption to
understand". A standard one-time pad is simpler and stronger, and the extra
complexity of multiplying large prime numbers doesn't really buy you anything
much to compensate.

~~~
ars
I don't intend for anyone to actually implement this. It's just to understand
how encryption can work. i.e. how it's possible for an operation in one
direction to be quick and easy, but the reverse operation is hard and slow.
(And why it's hard to implement properly.)

But you are right that as described it is a lot like a one time pad.
(Especially since if you encrypt a known message you can instantly find the
password.)

------
casca
The reason 256 bit AES keys are large enough is that in order to brute-force
them, one of 2 things needs to happen:

(1) We need to build computers out of something other than matter

    
    
      or
    

(2) A weakness in AES must be discovered that will need to reduce the search
space significantly

We can disregard (1) as it will probably require changing (almost) all
encryption algorithms that we currently use. (2) will most likely break all
key-lengths so any use of AES will be weakened.

~~~
aw3c2
People often mention quantum computing will break all encryption. Would that
be a non-matter computer?

~~~
Scaevolus
Not all. Academics refer to it as "post-quantum cryptography", see
<http://pqcrypto.org/>

From a talk by D. J. Bernstein <http://cr.yp.to/talks/2008.10.18/slides.pdf> :

    
    
        RSA: Dead.
        DSA: Dead.
        ECDSA: Dead.
        ECC in general: Dead.
        HECC in general: Dead.
        Buchmann–Williams: Dead.
        Class groups in general: Dead.
    
        Still alive:
        Hash-based cryptography.
        Example: 1979 Merkle hash-tree public-key signature system.
        Code-based cryptography.
        Example: 1978 McEliece hidden-Goppa-code public-key encryption system.
        Lattice-based cryptography.
        Example: 1998 “NTRU.”
        Multivariate-quadraticequations cryptography.
        Example: 1996 Patarin “HFE^V-” public-key signature system.
        Secret-key cryptography.
        Example: 1998 Daemen–Rijmen “Rijndael” cipher, aka “AES"

~~~
stcredzero
So, basically, we won't have any means of key exchange which isn't quantum
crypto.

~~~
marcosdumay
I don't realy like rocking a boat... but quantum cryptography can't realy be
used in practice.

Or, better, any practical implementation of quantum cryptography is
succeptible to attacks. And the entire thing still needs an authentication
method, guess what we use for authentication nowadays.

~~~
fjorder
It is being used in commercial systems (e.g. idquantique). Practical
implementations are prone to vulnerabilities, but none have been found that
cannot be remedied. Some techniques such as device independent or measurement
device independent QKD offer to make it far more difficult to come up with
attacks in the future too.

The #1 advantage of QKD is not that the methods being used today will be
immune to all attacks found in the future. It's that quantum states are
unclonable, so there's no way to archive cipher-text for future attacks, as
can be done with classically encrypted messages. e.g. If you send encrypt a
message and send it via email today, the encryption method has to stand up to
advances in algorithms and computational hardware for as long as the
information remains sensitive. If you send something via QKD, an eavesdropper
must break the protocol at the moment you send the message or it will be safe
for all time.

Authenticating strangers, as in credit card transactions, is something that
quantum computing may disrupt. QKD can be used safely by people who have met
at some point in the past, but we probably have a bit of time before CC
transactions need to be encrypted by QKD. i.e. While you should probably not
send medical records or state secrets via many classical encryption protocols
now, your CC info will change in a couple years so it's not as big of an issue
if your transactions are cracked a few years after that.

------
hartror
Wow computer science meets Greg Bear, I think I need to now go write a short
story featuring a supernova powered super computer.

~~~
keithpeter
" _And they strongly imply that brute-force attacks against 256-bit keys will
be infeasible until computers are built from something other than matter and
occupy something other than space._ "

Or about a computer that isn't made of matter as we understand it...

~~~
ars
How is what you said any different from what he said?

~~~
keithpeter
He said a super nova powered computer. A super nova is matter as we understand
it....

------
Jacobi
Using brute force is not very effective on 256 keys. But this doesn't exclude
the possibility of a breakthrough that reduce enormously the search space. For
example even for AES there is an attack faster than brute force by a factor of
about four ! [http://research.microsoft.com/en-
us/projects/cryptanalysis/a...](http://research.microsoft.com/en-
us/projects/cryptanalysis/aesbc.pdf)

------
cjg
Something that many of these answers fail to address is that a 256-bit key
isn't big enough, if you can do 2^128 computations.

This is due to the probability of key collision. See
<http://en.wikipedia.org/wiki/Birthday_attack>

Not that I'm saying 2^128 calculations isn't a lot, but compared to 2^256,
it's a tiny speck.

~~~
grandsham
a birthday attack reduces the number of keys you have to search by half, not
half the number of bits. This means that you would have to search 2^255 keys
instead of 2^256 keys.

~~~
pjscott
Look again. Finding a collision in a hash function with n possible values
takes an expected number of guesses proportional to sqrt(n). If n = 2^256,
then sqrt(n) = (2^256)^(1/2) = 2^(256/2) = 2^128.

------
Tichy
" To record a single bit by changing the state of a system requires an amount
of energy no less than kT, where T is the absolute temperature of the system
and k is the Boltzman constant."

How does that work? It seems odd that is is independent of the size of the
system.

~~~
marcosdumay
That comes from the second law of thermodynamics. Setting a bit on the
computer reduces its entropy, so it must dissipate enough heat to increase the
entropy of the Universe by at least the same amount.

Notice that this only applies to setting it into a known value. In theory
there are some operations that we can do without dissipating any heat.

~~~
Tichy
But how do they know how much energy a bit requires?

~~~
marcosdumay
As I said, that's by the second law of thermodynamics...

There is a nice <a
href="[http://en.wikipedia.org/wiki/Maxwell%27s_demon>tought](http://en.wikipedia.org/wiki/Maxwell%27s_demon>tought)
experiment</a> linking thermodynamics to information theory. And guess what,
experiments agree with the theory.

After you have the theoretical framewok done, it is just a matter of applying
the <a
href="[http://en.wikipedia.org/wiki/Boltzmann%27s_entropy_formula&#...](http://en.wikipedia.org/wiki/Boltzmann%27s_entropy_formula>Boltzmans)
entropy formula</a>, and you are done.

------
dfc
For further reference and a more detailed discussion of algo / key length
selection take a look at NIST's _Recommendation for Key Management_ [1],
specifically section 5.6 "Guidance for Cryptographic Algorithm and Key-Size
Selection."

[1]
[http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57_p...](http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57_part1_rev3_general.pdf)

------
ppierald
I have to note that the length and strength of your AES key is no different
than the complexity of your password. Once either is compromised, then you are
totally exposed. So your attacker will take the path of least resistance. He
can either brute-force the key or he can just break into your server and steal
your config file or his you over the head with the proverbial $5 wrench.

------
mtgx
So even a quantum computer wouldn't be enough then?

~~~
Devilboy
Quantum computers can, in general, provide up to a quadratic speedup over
classical algorithms and WILL in fact be enough. Once we have QCs all bets are
off.

~~~
VLM
No, not really. Run the same example from the article with a quadratic speedup
and see how scalable it is.

56 bit DES should be nervous. 256 bit AES, not so much.

There is a tiresome often repeated quantum computing meme or anti-pattern
where QC is a magic implementation such that "my magic can do anything I can
dream of". Well no, not really. Oh it could be powerful, maybe even
implementable, but not limitless.

~~~
apawloski
To clarify a bit further, only a few cryptosystems (certain public key
systems) are really threatened by quantum computers.

Theoretically, literature indicates that quantum computers are really good at
factoring large numbers [1], and they are really good at solving discrete log
problems [2].

So yes, QCs are theoretically able to crack in linear time some systems whose
security depends on those problems being hard (eg ElGamal, RSA). But systems
that don't rely on large primes/discrete logs (eg symmetric algorithms like
AES) _are not vulnerable_ to quantum computers. (At least not vulnerable in
the "throw them out, they're useless now" sense.)

In fact, there's even asymmetric cryptosystems that aren't threatened by
quantum computers [3]. Again, any system that doesn't rely on large primes, or
the difficulty of the discrete log problem, is not significantly threatened.

[1]<http://arxiv.org/abs/quant-ph/9503007>

[2][http://epubs.siam.org/doi/abs/10.1137/S0097539795293172?jour...](http://epubs.siam.org/doi/abs/10.1137/S0097539795293172?journalCode=smjcat)

[3][http://link.springer.com/chapter/10.1007%2F3-540-44586-2_2?L...](http://link.springer.com/chapter/10.1007%2F3-540-44586-2_2?LI=true)

------
pfortuny
I honestly think that the title should be '256 bits are enough against brute-
force' because otherwise this is way way way misleading.

------
donpark
IMO the most vulnerable part of AES is not the side-channels but key
generation. Compromise the source of entropies, preferably only for processes
with specific signatures, just enough to be crackable on-demand then capture
everything on the wire remotely.

------
NicoJuicy
Just use the slowest algorithm to delay brute-force attacks :)

~~~
zaptheimpaler
I believe this is the idea behind bcrypt - it can be made slower and slower
based on a parameter as larger computations become feasible.

~~~
merijnv
bcrypt is a hashing algorithm for securely hashing passwords, this is
something you want to be slow, yes.

However, the discussion in the link is about encryption, which you want to be
_fast_. A popular webserver serving HTTPS to thousands of clients can't afford
a 10x overhead on the speed of encryption.

~~~
VLM
Encryption and decryption speeds need not be symmetric. Salted passwords are a
stereotypical example... Lets say my password is "password" and I salt it with
a random 8 bit value to make rainbow tables 256 times longer than unsalted. I
can encrypt the salted password in one round.

However on the decrypt side a salty password is going to have to average 128
rounds before a match and a worst case failure / non-match means you have to
run ALL 256 rounds just to make sure.

Obviously we're talking salty passwords not secure web traffic, but the point
is off the shelf systems have existed for decades where the decrypt system is
orders of magnitude more expensive than the encrypt system. Implementing an
algo with those characteristics for web traffic "superficially seems feasible"
although the details are fuzzy.

As an example of a rough guess, 16 bits of salt would scale pretty well for
"thousands of clients" if the server and client are more or less similar
performance level (which within an order of magnitude or two is probably about
right). Simple salt is the wrong algo for this job, but...

------
lectrick
I think the 256 bits are a buffer against non-brute-force attacks, such as
undiscovered algorithm weaknesses which may speed up by some factor, the
cracking speed.

------
ck2
128bit will be crackable in 2030 with government-sized resources, last time I
read about it?

You can be sure taxdollars are powering mind-staggering supercomputers that
the public doesn't know about right now.

------
oellegaard
"640K ought to be enough for anybody." - Bill Gates, 1981

~~~
tyree732
What exactly are you trying to imply with this quote? It seems like you're
suggesting that Schneier's quote may become infamous one day should 256-bit
key cryptography become crackable, which it might, but you say nothing as to
how Schneier's argument could ever be wrong. He is saying that
thermodynamically speaking, brute-forcing 256-bit key symmetric cryptography
is unlikely to ever be possible. Do you think that to be false?

~~~
stcredzero
"1.21 × 1041 ergs/year ought to be enough for anybody."

Let me just live to see the day.

