TL;DR
Building your own cryptosystem – even with standard building blocks – quickly becomes “rolling your own” and carries significant risk. Avoid it unless you are a dedicated cryptography expert. Using well-vetted libraries is almost always the better choice.
What Does ‘Rolling Your Own’ Mean?
In cyber security, “rolling your own crypto” means designing and implementing your own cryptographic algorithms or protocols instead of using established, peer-reviewed standards and libraries. It’s generally a very bad idea because it’s incredibly easy to make subtle but devastating mistakes.
When Does it Become ‘Rolling Your Own’?
- Using Standard Algorithms Correctly: If you’re simply using well-established algorithms (like AES, SHA-256, RSA) from a reputable library and following best practices for key management and usage, you’re not rolling your own. This is fine – libraries handle the complex math correctly.
- Example: Using OpenSSL to encrypt data with AES in CBC mode using a randomly generated IV.
- Combining Algorithms: Combining algorithms (e.g., hashing a password then encrypting it) is starting to get risky, but still manageable if you understand the implications of each step and potential attacks.
- Example: Using PBKDF2 to derive a key from a password, then using AES to encrypt data. This requires careful parameter selection (salt length, iteration count)
- Modifying Algorithms: Changing even small parts of a standard algorithm is almost always a disaster. You’re likely introducing vulnerabilities.
- Example: Trying to speed up AES by reducing the number of rounds.
- Creating New Algorithms: Designing your own algorithms from scratch is definitely rolling your own. Unless you’re a cryptography PhD with years of experience, this will almost certainly result in a broken system.
- Example: Inventing a new block cipher based on bitwise operations.
- Implementing Protocols: Implementing cryptographic protocols (like TLS, SSH) is complex and prone to errors. Even experienced developers make mistakes here.
- Example: Writing your own version of the TLS handshake.
Why is Rolling Your Own So Dangerous?
- Subtle Bugs: Cryptography relies on complex mathematical principles. Small errors can create huge vulnerabilities.
- Known Attacks: Many attacks are well-known and documented. A custom system won’t benefit from the scrutiny of the security community.
- Side-Channel Attacks: Even correct implementations can be vulnerable to side-channel attacks (timing attacks, power analysis) that exploit physical characteristics of the hardware.
- Key Management: Secure key generation, storage, and distribution are critical. It’s easy to get this wrong.
Example Scenario
Let’s say you want to store passwords securely. Here’s a breakdown:
- Good: Using bcrypt or Argon2 from a well-maintained library. The library handles salting, hashing, and key stretching.
# Python example using bcrypt import bcrypt hashed = bcrypt.hashpw(b'mysecretpassword', bcrypt.gensalt()) print(hashed) - Risky: Using SHA-256 to hash passwords directly, then storing the hash.
import hashlib hash_object = hashlib.sha256(b'mysecretpassword') hex_dig = hash_object.hexdigest() print(hex_dig)This is vulnerable to rainbow table attacks and requires additional salting, which you need to implement correctly.
- Very Bad: Creating your own hashing function based on bitwise operations.
Alternatives
- Use Established Libraries: OpenSSL, libsodium, Bouncy Castle, cryptography (Python), etc.
- Follow Best Practices: Use strong key lengths, proper padding schemes, and authenticated encryption modes.
- Consult with Experts: If you have complex security requirements, get help from a qualified cyber security professional.