Re: Encryption
Re: Encryption
- Subject: Re: Encryption
- From: Robert Tito <email@hidden>
- Date: Fri, 02 Jan 2004 00:00:08 +0100
On 1-1-2004 23:43, "Nicko van Someren" <email@hidden> wrote:
>
On 1 Jan 2004, at 21:56, Robert Tito wrote:
>
>
> Besides, all the encryption functions are completely described on their
>
> appropriate websites, as well as C/C++ code to create them. In stead of
>
> using one engine (128 bits generally) that can be cracked nowadays
>
> within 20
>
> minutes a mix seems more appropriate: dont use static encryption in
>
> stead
>
> use a flexible multiple engine based on synchronized timestamps
>
>
I have to say that this is bad advice on a couple of counts.
>
>
Firstly, 128 bit symmetric encryption is perfectly safe for general use
>
when performed properly. If your keys are random then it will take
>
about 2^127 tries to guess it; if every person on the planet had a
>
machine that could try 1 billion keys a second then you'd still be
>
waiting a thousand times longer then earth has existed to try that
>
many. As such a mix of encryption systems is unnecessary and simply
>
adds complexity, which leads to bugs, which can lead to insecurity.
>
>
Secondly, though it's true that you should not use static encryption
>
keys using keys based on time stamps is just as dangerous (one of the
>
early implementations of SSL was broken for doing exactly that).
>
>
The best way to handle keys is very application dependent. If you are
>
trying to encrypt bodies of data so that the same user can come back
>
later and decrypt it then an effective way to handle the key is to get
>
them to enter a pass phrase and run it through a hash function such as
>
SHA1. If you're doing this it's a good idea to use what's called a
>
"salt" where you take a bunch of random bytes that are appended to the
>
pass phrase before you hash it to make the key and you also write the
>
"salt" data, unencrypted, into the file. This is useful for stopping
>
the attacker pre-computing the hashes of common passwords.
>
>
If you're trying to encrypt data so that it can then be sent to a
>
remote recipient who is not necessarily already know to the user then
>
you're best bet is to use public key encryption. The crypto library in
>
from OpenSSL (in /usr/lib/libcrypto.dylib on the standard distribution)
>
can do all of this, though the use is it is beyond the scope of a
>
posting here. Another option for quality, interoperable public key
>
crypto is the framework that comes with PGP for the Mac. It's
>
commercial but worth considering if you want to use public key
>
cryptography and have someone else deal with all the hassle of trust
>
management.
>
>
Cheers,
>
Nicko
>
>
Nicko
How well meant your advice is, and a happy new year to you, it doesnt give
you status 4 in encryption, meaning top secret government level. It takes a
mere 15-20 minutes to crack any single 128 bits engine so I think you have
either NO knowledge about encryption and or forensic research. Verisign for
instance is one of the least safest way to encrypt: the man in the middle is
always possible, how hard they try to prevent it.
Believe me, we have an engine that will take you 1 over 10^1256 attempts to
crack: good luck.
128 bits is cracked in no time at all.
Regards
Rob
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.