Re: Insecure cryptographic algorithms to avoid using?
- From: Ertugrul Soeylemez <never@xxxxxxxxxxxxxx>
- Date: Mon, 15 Jan 2007 05:39:48 +0100
"ykgoh" <gohyongkwang@xxxxxxxxxxx> (07-01-14 19:11:56):
First of all, I'm not a cryptography researcher, just a developer who
needs encryption for my software, so I figured the best way would be
to rely on a well-tested algorithm that has been scrutinized and
tested by experts. btw, I'm not protecting national security secrets,
just to encrypt some user passwords.
First of all, you probably don't even need a cipher. For password
purposes, in almost all cases a hash function is even more approriate
than a cipher, because saving passwords is bad practise.
Imagine you would like users to authenticate. You need a hash function
H. Where K is the password, save H(K). If somebody tries to login,
check the entered password P against the saved value. The user (almost
certainly) did enter a correct password, when the hashes of P and K
match: H(P) = H(K).
You can use this for a file encryption utility as well, if you insist on
warning the user about a wrong password. Encrypt the file with K and
save H(K) in the file. If a user want's to decrypt using the key P,
check that H(P) = H(K), and if yes, decrypt with P.
The best candidate would be AES.
There is no `best candidate', but rather a few `most appropriate'
candidates.
But I've been looking around Wikipedia and there're lots of other
algorithms available that are considered secure. E.g. IDEA, Blowfish,
RC4 and TEA.
RC4 is a good pseudo-random number generator for games and simulators,
but for cryptographic purposes, I would suggest other generators.
Exclude RC4, and don't use the original TEA. Use XTEA or XXTEA instead.
Although IDEA is secure, its slow performance and, more notably, its
patents make me refrain from using it.
So I'm wondering is it still safe to consider and use these
alternative algorithms as well?
Depending on the purpose, yes. For example, Blowfish is still a good
algorithm, if memory doesn't cost much.
What are the cryptographic algorithms that have already been proven to
be insecure fundamentally or inadequately secure due to key length as
of 2007, and thus should be avoided?
A lot of, but most notably DES and RC4.
When would be it be appropriate to use block cipher and stream cipher?
For block cipher, padding has to be used to round off the length of
the block to the required block size. However, encryption and security
is still possible for both even if the plaintext length is uneven and
doesn't align nicely to block size since padding can be used.
Their designs are totally different. Stream ciphers are essentially
functions of a plaintext unit P_i and the i-th member of some sequence
(or `stream') S:
C_i = P_i + S_i
Here, the + operator doesn't necessarily refer to addition. It can be
any revertible operation. The security of the algorithm depends on the
randomness of S. Basically every secure pseudo-random number generator,
together with bitwise XOR, is a stream cipher.
A block cipher is a function of a plaintext unit P_i and the key K:
C_i = f(P_i, K)
The security of a block cipher depends on the encryption function f
(which is a permutation), and the strength of the key K.
In other words: Using a block cipher doesn't necessarily mean that you
need padding (see IDEA), and using a stream cipher doesn't necessarily
mean that you don't need to pad (see TEA).
The difference between a block cipher and a stream cipher is not its
unit size, but its entire design idea. Use a stream cipher, where you
continuously send data over a wire. Use a block cipher, if you need to
make changes in the middle of the text.
Regards,
E.S.
.
- References:
- Prev by Date: Re: Insecure cryptographic algorithms to avoid using?
- Next by Date: Re: Insecure cryptographic algorithms to avoid using?
- Previous by thread: Re: Insecure cryptographic algorithms to avoid using?
- Next by thread: Re: Insecure cryptographic algorithms to avoid using?
- Index(es):
Relevant Pages
|