SHA-3 is KECCAK

[Chris Cain]

On Tuesday, 21 January 2014 at 09:58:34 UTC, Uranuz wrote:
> I'm slightly disappointed that then more I read different 
> articles on IT forums then less I understand something. And 
> there are several opposite ideas that stunning me.
>  1. All security systems, cipher, etc can be hacked If someone 
> wants it

A bit true and untrue at the same time. Let's look at it from the 
perspective of "feasible attacks" first: It's impossible to prove 
one way or the other. On the other hand, the only way we can 
verify something as secure is we have many "Really Smart People" 
look at it and see if they can come up with anything to attack it 
(and often there are often huge incentives provided to discover 
these weaknesses). It stands to reason if many motivated RSP 
can't discover a weakness, the likelihood of some joe-shmoe 
discovering a weakness is extremely low. It's possible but just 
not likely.

If we accept "infeasible attacks" also, then this statement is 
absolutely true. If you have some motivated individual who is 
willing to sit around until after the sun burns out (this is NOT 
an exaggeration but actual calculation), then they can eventually 
brute force a single AES256 instance. Since I'll be long dead and 
so will my children and my children's children (etc), I'm not 
concerned about such attacks.

With all that said, if you use a system that has NOT been 
reviewed by many motivated RSP, then you've (likely) got a 
ticking time bomb. That's the reason for the idea below ("Do not 
reinvent the wheel"). It's sometimes really difficult to discern 
whether you're using an accepted standard way of doing things or 
not, however. Even using the "accepted standard primitives" can 
be done in non-standard/weak ways.

Consider using AES256 poorly:
1. Take any password
2. hash it with MD5
3. Use that hash as the key (pad the extra bits with 0s) to 
encrypt something using AES256 in ECB mode

That's not strong for many reasons. But in particular step 1 is 
very vulnerable to attacks. If you have anything less than a 8 
character password, such a scheme is very easy to break. As a 
general rule, passwords should be no less than 12 characters long 
(my passwords are stored in a password manager with 20+ 
characters in length and my computer is encrypted with a password 
of length 20+ as well) or that'll be the weak point in the system.

MD5 is trash for a variety of reasons but the fact that 
collisions have been discovered means that it's more likely that 
multiple strings will hash to the same hash value. So despite 
being 128-bits long, it has the apparent value of something much 
lower. It's much more likely, for instance, that your 
50-character password will hash the same as a 7-character 
password. Unless you specifically chose your password in such a 
way to avoid such a thing, it's impossible to know whether you've 
chosen an unlucky password where such a thing is true.

Since step 3 involves padding the extra bits with 0s, that means 
AES256 is no more powerful than AES128. (this would be true even 
if you alternated between 0 and 1 or any number of other 
patterns, by the way) Furthermore since MD5 has been proven to 
not actually have the value of 128-bit, the actual encryption 
power is even lower than that.

Furthermore, using ECB mode makes it insecure to certain types of 
attacks too.
http://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#Electronic_codebook_.28ECB.29
(look at the image ... you can discover what a message is without 
actually decrypting it! Yes, this works with text too, but it 
requires a bit more analysis that just looking at it.)

Despite AES256 itself being very secure against attacks, the 
scheme used makes it very vulnerable to a variety of attacks. The 
only way to know whether it's good or not is to research 
yourself, or, better, ask a group of experts to break it.

(The "ask a group to break it" really reminds me of Andre's 
"Destroy" philosophy)


One last thing to consider for this: there are usually 
side-channel attacks that can circumvent most security systems. A 
famous attack is known as the "rubber hose attack":
Take some guy who has information you want (such as a password to 
access a system or decrypt something important) and beat him with 
a rubber hose until he tells you what you need to know.
http://en.wikipedia.org/wiki/Rubber-hose_cryptanalysis

So if you also start expanding your scope to things like 
side-channel attacks, the difficulty of implementing a truly 
secure system goes WAAAY up. The probability of all of those 
side-channel attacks being used is fairly low, however. Some of 
them are actually pretty important, though. Like timing attacks.

In general, though, it is possible to get a system secure enough 
that such things become too unlikely to worry about. It's 
absolutely worth putting forth the effort to secure things 
despite it being very hard to nearly impossible to make things 
"perfectly" secure.

>  2. Do not reinvent the wheel. All have been invented already.

Do not reinvent the wheel: absolutely true.
All have been invented already: Not necessarily.

If there exists a solution to the problem you're trying to solve 
(and it's likely that such a solution does exist), use the 
existing solution as long as you have good reason to believe it 
to be strong against attackers (a solution described by some 
random guy on a forum that isn't providing citations is an 
example of something you shouldn't necessarily trust ... the 
strength of someone's solution has no relation to how smart they 
think they are). At the very least you should be using 
cryptographic primitives to create your solution (such as using 
AES or one of the SHAs, particularly SHA2). You should also "peer 
review" your solution with others when possible (even using 
accepted primitives can result in weaknesses). Do _not_ hide your 
solution and hope no one discovers how it's done as your form of 
security ("security through obscurity"). That is extremely 
unreliable and will almost certainly result in a successful 
attack if you are guarding anything of value.

>  3. If you use standart implementation it's high risk than it 
> was cracked already.

Very false. Look at my response to #1 again. The standard 
implementations have been reviewed by many very intelligent 
experts in the field and they'll have some pretty good tricks up 
their sleeve to discover potential weaknesses. A more recent 
example, the Dual_EC_DRBG algorithm of RSA infamy, was theorized 
to be weak in November 2007 because of the constants used. 
Although no attack was actually discovered at the time, the fact 
that a RSP saw the likelihood of a flaw in it shows that these 
guys are _very_ good at spotting weaknesses before they become an 
actual issue. Indeed recently it was shown to actually be weak 
against the NSA (who paid the RSA to include the algorithm in 
their standards).

This type of idea usually come from amateurs who have relatively 
low experience in cryptography. It's an idea that, on the surface 
or in theory, looks pretty reasonable. But experience teaches you 
that this is false in practice. This whole concept is derived 
from "use something that no one has seen yet so they haven't 
discovered the weakness yet" ... or, alternatively, "Security 
through Obscurity". An example is "hide a key to your house under 
a rock in front of your front door instead of carrying it 
around." Or "use a lock that has a single pin but the pin is 
located on the horizontal instead of the vertical". Using 
something non-standard hoping to avoid issues will NOT actually 
help you avoid issues. At best you can hope to delay an attack 
whereas things being open means that, despite many motivated RSP 
having looked at it, the system remains secure from attacks.

Look at this wikipedia article for a full explanation of why 
"avoid the standard implementations"/"security through obscurity" 
is bad:
http://en.wikipedia.org/wiki/Security_through_obscurity

FWIW, if you're "smart enough" you might be able to come up with 
a system using Security through Obscurity on parts of it that 
doesn't significantly negatively impact actual security of your 
system. Unfortunately, no one is able to accurately gauge if you 
are "smart enough". However, here's a reasonable heuristic:

Do you have 4 years of specialized training/experience in 
cryptography alone? If no, then you're probably not "smart 
enough". If yes, then you likely know the risks inherent to 
rolling your own solution without others reviewing it and you'll 
know whether its worth the risks to implement it so it's up to 
you.

If you have no experience in cryptography but think that it's 
bogus that you'd actually need experience to do cryptography and 
think you can do it anyway: You're almost absolutely not "smart 
enough" but you're probably "dumb enough" to ignore my advice (or 
anyone's for that matter) anyway, so it's a waste of time to 
discuss it. Do what you will, but hopefully after you fail a few 
times (and you will) you'll get the hint.

>  4. Is it really essential to someone tho crack you security.

I don't understand. Could you rephrase this?



Okay, all of that was a bit too much, but hopefully you'll find 
it helpful.