Hot answers tagged

135

Of course you can start small and implement your own algorithms. But do not assume they provide any security beyond obfuscation. The difficult thing when it comes to cryptography is finding reasons why something actually is secure. You won't be able to decide that within months and if you feel like you are at that point, you are most probably wrong. It is ...


85

What you do really is hashing: you built a hashing function out of a block cipher. Incidentally, "encryption of a known value with the password as key" is how the traditional DES-based crypt scheme for Unix was designed. On the plus side, your construction includes the user name, which partially provides the effect of a salt: parallel cracking is ...


77

Don't roll your own crypto. Don't invent your own encryption algorithm or protocol; that is extremely error-prone. As Bruce Schneier likes to say, "Anyone can invent an encryption algorithm they themselves can't break; it's much harder to invent one that no one else can break". Crypto algorithms are very intricate and need intensive vetting to be ...


47

Don't use encryption without message authentication It is a very common error to encrypt data without also authenticating it. Example: The developer wants to keep a message secret, so encrypts the message with AES-CBC mode. The error: This is not sufficient for security in the presence of active attacks, replay attacks, reaction attacks, etc. There are ...


41

The problem with client sided Obfuscation/Protection is that the attacker will always win. Your code runs on his PC so he can intercept and manipulate everything in the end. In the specific case of .NET it might make sense to apply basic obfuscation to remove function names for example but free tools are perfectly fine for that. To answer your question a ...


37

Coursera Here's my 2 cents: Join the Coursera Cryptography online class: Coursera: Stanford University, Professor Dan Boneh, Cryptography I The class takes six weeks. Each week there are several lecture videos, a graded quiz and an optional programming assignment. (And these assignments involve implementing crypto parts.) At the end of the six weeks ...


36

Be careful when concatenating multiple strings, before hashing. An error I sometimes see: People want a hash of the strings S and T. They concatenate them to get a single string S||T, then hash it to get H(S||T). This is flawed. The problem: Concatenation leaves the boundary between the two strings ambiguous. Example: builtin||securely = ...


29

The recommendations you cite are kind of overkill. One point to take into account is that beyond a certain level (e.g. on key size or hash function output size), all functions are "unbreakable with foreseeable technology" and it is a bit delicate to compare them. Stating that SHA-512 is "more robust" than SHA-256 means that you are imagining that SHA-256 ...


29

Don't reuse nonces or IVs Many modes of operation require an IV (Initialization Vector). You must never re-use the same value for an IV twice; doing so can cancel all the security guarantees and cause a catastrophic breach of security. For stream cipher modes of operation, like CTR mode or OFB mode, re-using a IV is a security disaster. It can cause the ...


29

Make sure you seed random number generators with enough entropy. Make sure you use crypto-strength pseudorandom number generators for things like generating keys, choosing IVs/nonces, etc. Don't use rand(), random(), drand48(), etc. Make sure you seed the pseudorandom number generator with enough entropy. Don't seed it with the time of day; that's ...


21

Start by breaking, not building your own. There's a worrisomely large number of stackexchange posts by people who've written their own algorithms. Take a look around and figure out what's wrong with them. (Don't look at the posted answers.) [Good searches include "Is this secure" and "whats wrong with this algorithm".] Only when you've found issues in ...


20

Don't use a block cipher with ECB for symmetric encryption (Applies to AES, 3DES, ... ) Here is a post and a very similar Microsoft KB article regarding how ECB mode results in code that isn't encrypted. Also see this similar post from Rook Plain text message: The same message encrypted with ECB mode (doesn't matter what cipher you use): The EXACT ...


20

Don't use the same key for both encryption and authentication. Don't use the same key for both encryption and signing. A key should not be reused for multiple purposes; that may open up various subtle attacks. For instance, if you have an RSA private/public key pair, you should not both use it for encryption (encrypt with the public key, decrypt with the ...


17

Kerckhoffs's principle: A cryptosystem should be secure even if everything about the system, except the key, is public knowledge A wrong example: LANMAN hashes The LANMAN hashes would be hard to figure out if noone knew the algorithm, however once the algorithm was known it is now very trivial to crack. The algorithm is as follows (from wikipedia) : ...


16

PasswordDeriveBytes implements the PBKDF1 key-derivation function. A KDF is a function which transform a piece of secret data (here, a "password", i.e. the kind of data which fits in a human brain and can be typed with human fingers) into a sequence of bits adequate for algorithms which need a symmetric key (e.g. symmetric encryption). A KDF is not meant for ...


16

Let's be clear: Obfuscation is not there to be a form of security that is subject to scrutiny. It will fall down as soon as someone actually tries to get around the obfuscation and just makes things harder on the attacker. The purpose of obfuscation is to dissuade potential attackers from getting into the system without a large amount of effort, which may ...


15

MD4 and MD5 are not encryption algorithms. They are one-way hash function designed for cryptography. It is important you understand the difference. MD5 is a slightly modified version of MD4 that improves its security somewhat. Another thing that is important to understand is that neither of these function are considered safe for use in cryptography: MD4 ...


14

Using computer random number generators to produce keys, it is secure? It depends on your threat environment, exposure, and overall system security. Given the difficulty in implementing robust secure systems, and assuming that the thing you are protecting is not of high value (to others), using your own computer to generate random numbers is likely ok. ...


13

Try to avoid using passwords as encryption keys. A common weakness in many systems is to use a password or passphrase, or a hash of a password or passphrase, as the encryption/decryption key. The problem is that this tends to be highly susceptible to offline keysearch attacks. Most users choose passwords that do not have sufficient entropy to resist such ...


13

In a cryptographic protocol: Make every authenticated message recognisable: no two messages should look the same A generalisation/variant of: Be careful when concatenating multiple strings, before hashing. Don't reuse keys. Don't reuse nonces. During a run of cryptographic protocol many messages that cannot be counterfeited without a secret (key or ...


13

Bruce Schneier's Applied Cryptography is a must read if you want to start studying this field. I am surprised that nobody suggested it before. And yes, you need to know a lot about crypto even before trying to roll your own algorithms for fun. Don't even think of using them for real-world problems, though -- there's already a lot of bad crypto around. ...


12

The NIST approves of PBKDF2 when hashing and storing passwords, however that is not it's original intended purpose. Notably, StackExchange also uses PBKDF2 for the same purpose. Source code is available here. See this answer for a comparison between BCrypt and PBKDF2. BCrypt is the the more conventional method of storing passwords. I'm considering ...


12

At least one thing you can improve rather easily: You can simply store the IV in the database next to the encrypted data. The IV itself is not supposed to be secret. It usually acts as a salt, to avoid a situation where two identical plaintext records get encrypted into identical ciphertext. Storing the IV in the database for each row will eliminate the ...


12

There are two ways you can save authentication information in the browser: Cookies HTML5 Web Storage In each case, you have to trust that browsers are implemented correctly, and that Website A can't somehow access the authentication information for Website B. In that sense, both storage mechanisms are equally secure. Problems can arise in terms of how ...


11

Never hardcode passwords or crypto keys in your program. The general rule of thumb is: the only credentials you should store on a user's machine are credentials associated with that user, e.g., credentials that enable that user to log into his/her account. You should not store your developer credentials on the user's machine. That's not safe. You have to ...


11

There is plenty of malware out there that is written in .NET, but as a C# dev I can see why many malware authors avoid it: Easy to disassemble and reverse engineer. Easy for AV to detect use of certain classes and functions. Requires .NET on the box (older XP boxes might not have it, or might only have .NET 2.0) Harder to do anti-debug tricks in .NET than ...


11

No, no, no, no, no. Encryption is not hashing. You need to use a strong hashing algorithm like bcrypt or pbkdf2 instead. You can use a library like Bcrypt.Net. With the library, hashing a password is simply a matter of calling, BCrypt.Net.BCrypt.HashPassword(password, workFactor); Verification is just as easy, BCrypt.Net.BCrypt.Verify(password, ...


10

The quoted answer is my response to what is the most secure crypto in .NET. My recommendations (both for high- and low-powered devices): Symmetric cipher: AES-128 Asymmetric cipher: RSA with 2048 bit key or ECDSA/ECDH with 256 bit key Hash: SHA-256 Message Authentication Code: HMAC with SHA-256 Stream cipher: AES-128 in CTR-mode


10

What you implemented is not Diffie-Hellman, and has no strength at all. You are being confused with the use of the '^' character. In C-like programming languages, '^' is the operator for a bitwise exclusive-or (a "XOR"). When writing mathematics in ASCII, it is customary to denotes exponentiation with the '^' character -- and it is not a XOR at all ! This ...


10

Even if you use CTS, you still need an initialization vector (IV) which MUST (I insist, MUST) be generated anew for each file with a cryptographically strong pseudo-random number generator. So you will not be able to fit all of it without increasing the size. This is unavoidable, as long as you use a "normal" block cipher. Also, if you need encryption, then ...



Only top voted, non community-wiki answers of a minimum length are eligible