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.
