Cryptography is the science of protecting secrets. As a result, it’s designed to make it impossible for an unauthorized party (like a hacker) to gain access to the protected data. While early encryption algorithms had significant flaws and were easily broken, the state of the art in encryption has gotten a lot better.
That being said, cryptography can be broken under the right circumstances.
The first step in breaking cryptography is identifying the cryptographic algorithm in use. This can be accomplished in a number of ways including:
- Manual reverse-engineering
- Keyword searches for algorithm names
- Analysis of an executable’s dependencies
- Ciphertext analysis (e.g., observing block lengths)
With this information in hand, it’s time to start looking for an exploitable vulnerability.
Exploiting cryptographic vulnerabilities
Modern cryptography is secure by design. However, security by design doesn’t necessarily mean perfect security. If cryptography is poorly implemented or misused, vulnerabilities can be created that a hacker can exploit. Many different ways exist to exploit modern cryptosystems.
Encryption algorithms are designed to ensure that only the sender and recipient of a message are able to access it. This access is protected using secret keys that are known only to the two authorized parties.
However, key management is one of the most common ways that cryptography fails. Key management systems have the classic problem of having to balance usability and security, and usability often wins out. Encryption keys are often based off of or protected by passwords. Since many users commonly use weak or reused passwords, stealing the encryption key is often an effective way of bypassing cryptographic protections.
Stream cipher vulnerabilities
Encryption algorithms come in two main flavors: block and stream ciphers. In general, block ciphers are more intuitive and easier to use, but less efficient (since you need to (Read more...)
*** This is a Security Bloggers Network syndicated blog from Infosec Resources authored by Howard Poston. Read the original post at: http://feedproxy.google.com/~r/infosecResources/~3/JHEEj2Ipuak/