Tag Info

Hot answers tagged

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 ...


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

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 ...


25

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 ...


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 ...


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 ...


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) : ...


15

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 ...


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 ...


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 ...


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 ...


9

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 ...


9

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 ...


8

Don't use the same key in both directions. In network communications, a common mistake is to use the same key for communication in the A->B direction as for the B->A direction. This is a bad idea, because it often enables replay attacks that replay something A sent to B, back to A. The safest approach is to negotiate two independent keys, one for each ...


8

Don't use insecure key lengths. Ensure you use algorithms with a sufficiently long key. For symmetric-key cryptography, I'd recommend at least a 80-bit key, and if possible, a 128-bit key is a good idea. Don't use 40-bit crypto; it is insecure and easily broken by amateurs, simply by exhaustively trying every possible key. Don't use 56-bit DES; it is not ...


8

El Gamal encryption allows for multiplication. This occurs within the group on which El Gamal runs; hence you are multiplying numbers modulo a given prime, not "plain" integers. If you can multiply you can divide (inversion in a group of size q is done by raising to the power q-2, so this is a matter of performing some multiplications). El Gamal is ...


8

You should never put the password in the code. In general your connection settings live outside the compiled application code; for C# that would generally be in an app.config XML file, encrypted if need be. But either way, if the application is able to make direct connections to the database, it has to know the password, and there is nothing you can do to ...


7

I don't know enough about C#'s serialization to know whether it is a security risk, but I can tell you this: In Java, it is not safe to unserialize untrusted data. There are a number of subtle security pitfalls that can really screw you over. If you are guru-level, you can probably avoid the pitfalls, but an average developer probably has no clue about ...


7

An example of practical use of PHE (and El Gamal in particular) is Helios Voting. With it you can publicly store encrypted voted ballots in the cloud, and also allow the public to both add them up to confirm the vote counts for each candidate, and to check that their own vote was indeed included in the total, without having a receipt that could prove how ...


7

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 ...


7

You are using Rfc2898DeriveBytes, which implements PBKDF2: that's good. You are producing a whooping 128 bytes of output, which is total overkill for password verification. 128 bits, i.e. 16 bytes, are sufficient. 128 bytes don't harm, except that they make for bulkier strings to store in your database. You are using 10000 iterations, which might be a bit ...


6

Unless I've missed something, PasswordDeriveBytes - and other PBKDF implementations - are not intended for storing passwords, nor are they to be used instead of a "typical" hash. What it is intended for, is to create an encryption key, for symmetric encryption, based on a user-provided password. To clarify, consider the following situation: You have ...


6

In some countries, IDEA is patented and redistributing an implementation of it requires it to be licensed. IDEA was a default cipher used in early versions of PGP. For backward compatibility, it is included in OpenPGP which Bouncy Castle implements. For your case (a new application), get the distribution without it and use AES instead.



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