Unit 2 Asst2 Essay

Submitted By mikerivera
Words: 1055
Pages: 5

How to determine if you are vulnerable
Proprietary encryption algorithms are not to be trusted as they typically rely on ‘security through obscurity’ and not sound mathematics. These algorithms should be avoided if possible.
Specific algorithms to avoid:
MD5 has recently been found less secure than previously thought. While still safe for most applications such as hashes for binaries made available publicly, secure applications should now be migrating away from this algorithm.
SHA-0 has been conclusively broken. It should no longer be used for any sensitive applications.
SHA-1 has been reduced in strength and we encourage a migration to SHA-256, which implements a larger key size.
DES was once the standard crypto algorithm for encryption; a normal desktop machine can now break it. AES is the current preferred symmetric algorithm.
Cryptography is a constantly changing field. As new discoveries in cryptanalysis are made, older algorithms will be found unsafe. In addition, as computing power increases the feasibility of brute force attacks will render other cryptosystems or the use of certain key lengths unsafe. Standard bodies such as NIST should be monitored for future recommendations. Specific applications, such as banking transaction systems, may have specific requirements for algorithms and key sizes.
How to protect yourself
Assuming you have chosen an open, standard algorithm, the following recommendations should be considered when reviewing algorithms:
Symmetric:
Key sizes of 128 bits (standard for SSL) are sufficient for most applications
Consider 168 or 256 bits for secure systems such as large financial transactions
Asymmetric:
The difficulty of cracking a 2048 bit key compared to a 1024 bit key is far, far, far, more than the twice you might expect. Don’t use excessive key sizes unless you know you need them. Bruce Schneier in 2002 (see the references section) recommended the following key lengths for circa 2005 threats:
Key sizes of 1280 bits are sufficient for most personal applications
1536 bits should be acceptable today for most secure applications
2048 bits should be considered for highly protected applications.
Hashes:
Hash sizes of 128 bits (standard for SSL) are sufficient for most applications
Consider 168 or 256 bits for secure systems, as many hash functions are currently being revised (see above).
NIST and other standards bodies will provide up to date guidance on suggested key sizes.
Design your application to cope with new hashes and algorithms

Password hashing works on preimage resistance: the password hashing process should be such that it is not computationally feasible to find an input (a password) matching a given output (the hash), save by trying a lot of potential inputs and "get lucky". The "get lucky" attack is still a concern, because passwords are chosen by human users, who are not as imaginative and random as could be wished for; which is why we need more than a simple hash function (we need salts, we need slowness; see this). However, collisions have no impact on the security of password hashing. The ability to generate collisions at will does not give extra cracking power to the attacker.
As others have pointed out, collisions can be used for attacks in other setups involving signatures. These are scenarios where the attacker can:
1. generate colliding pairs of messages, with sufficient control on the format of these messages so that one message looks "innocent" and the other suits the attacker's goals;
2. have the innocent-looking message signed by a third party whose signature function begins by hashing the message "as is".
Under both these conditions, the third party will produce the signature, which will be valid (as far as signature verifiers are concerned) for both messages. This is like having the signer issue a signature on a message without showing it to the signer. A demonstration has been done in 2008 with the "messages" being X.509 certificates, and