AES BROKEN
Images are sometimes not shown due to bandwidth/network limitations. Refreshing the page usually helps.
You are currently reading a thread in /g/ - Technology
You are currently reading a thread in /g/ - Technology
Seriously.
http://blog.cr.yp.to/20151120-batchattacks.html
>>51443291
i aint clickin that shit nigga
Good read, I particularly liked the last bit
>what happens if the algorithmic problems facing the attackers aren't actually the algorithmic problems we're studying? In particular, what happens if the attack problems are easier than the problems we're studying?
>Maybe we're starting from the wrong cost metric for algorithms. For example, maybe we're using the oversimplified "operations" cost metric that I mentioned before, counting random access to a large array as a single "operation" when in fact it's much more expensive than an arithmetic operation. (Sometimes people say that counting "operations" is an underestimate of actual cost and is therefore safe; but this is part of what went wrong with the Silverman predictions.) Maybe we're optimizing algorithms for mass-market easy-to-program Intel CPUs, while the attacker is optimizing for special-purpose chips with much more parallelism and with fancy networks on chip. Maybe the attacker has a quantum computer, making some operations feasible while we normally think of those operations as being insanely expensive.
>Or maybe we're setting our cost limits too low. Maybe we're studying the problem of setting public factorization records using academic computer clusters, while the attacker is studying the problem of factoring 1024-bit keys as quickly as possible using billion-dollar clusters.
>Or maybe, in an effort to advertise attractively simple problems, we've oversimplified the problem of attacking the actual cryptosystem. Maybe we're studying the problem of recovering a signature key while the attacker is studying the actual problem of forging signatures. Maybe we're studying the problem of attacking one key while the attacker is studying the actual problem of attacking a large batch of keys. This oversimplification is surprisingly common, and is exactly the reason for this blog post.
>>51443291
https://web.archive.org/web/20151120215950/http://blog.cr.yp.to/20151120-batchattacks.html
>>51443291
Got a TLDR for that? All I have to read it now is my phone and I won't be home for a few more hours.
>>51444685
I think that the idea is that it may be the case that AES 128 might have duplicate keys for a given ciphertext.
>>51443291
>mfw Mr Robot needs to rewrite season 2 now
>>51443291
So what should I encrypt my hard drive with then?
>>51443291
>AES BROKEN
>2^126 guesses to break a key.
No.
>>51448107
Serpent :^)
>>51448118
So.. given the NSAs resources, you think it will still take them an eternity to crack 1 key?
so the solution...
is a longer key...
instead of 256 characters, 512!
>>51448204
If it takes 2^126 guesses, then yes.
>>51449011
without calling me a retard what's 2^126 mean? maths isn't my strong point
>>51449107
2 to the power 126,i.e., big number
>>51449124
thanks anon, I'm gunna buy some maths books and up my game I fell like a fucking idiot half the time
>>51449107
85,070,591,730,234,615,865,843,651,857,942,052,864 possible guesses
>>51443291
>>51444685
Got home and read it. I think they're talking about attacking multiple sets of encrypted data that were encrypted with different keys at the same time.
>>51443774
>Maybe the attacker has a quantum computer
Then you're fucked until quantum-safe encryption becomes a thing.
>>51449408
Only asymmetric encryption will be broken by quantum computing. AES will be fine.
>>51449520
Yeah, it's just we're left with the question of how to share symmetric keys.
Also, is ECC quantum safe? I know it's supposed to be safe if P=NP...
>>51449520
>AES will be fine
the whole point of the blog post is from what we KNOW it will be safe, that doesn't mean there isn't something we haven't thought of or some new algorithm previously unknown.
>http://blog.cr.yp.to/20151120-batchattacks.html
They're talking about AES-128, nobody uses that crap anymore.
>>51449649
So, if I'm right, the graphics telling me thaat breaking cryptography, if you're using decent key length, should be all but impossible with current technology, without some kind of ridiculous tinfoil backdoor.
>Using anything touched by the NSA
>MUH AUDITS MUH STANDARDS MUH MILLIONS OF NECKBEARD EYES LOOKING AT THE CODE
>>51448118
Quantum processors might.
How do you know someone already hasn't solved p=np?
>>51449107
2 = 2^1
2 * 2 = 2^2
2 * 2 * 2 = 2^3
Since it doubles every time you get to insanely high numbers really fast.
Someone needs to translate this in a way that pleb tier developers like me can understand
How can we secure our web apps with ECC? How can we secure or Lanucks PCs and SSDs with ECC?
>>51443291
im glad i deleted my cp long ago xd
>>51449107
Take a 2 and times it by 2 126 times.
2x2x2x2x2x2x2x2x2....x2x2
It's roughly: 85000000000000000000000000000000000000. (8.5x10^37)
In perspective, there have been:
13.7 billion years since the start of the universe
that's 10^20 milliseconds.
Let's say an attacker can do... 100 billion attempts a second.
Over 13.7 billion years that would be 10^28 attempts.
generally I could keep going but the number is so huge that it would take every computer on the planet thousands of billions of years.
>>51443291
>cr.yp.to
