1108

Note: This answer was written in 2013. Many things have changed in the following years, which means that this answer should primarily seen as how best practice used to be in 2013. The Theory We need to hash passwords as a second line of defence. A server which can authenticate users necessarily contains, somewhere in its entrails, some data which can be ...


444

I was one of the implementers of JScript and on the ECMA committee in the mid to late 1990s, so I can provide some historical perspective here. The JavaScript Math.random() function is designed to return a floating point value between 0 and 1. It is widely known (or at least should be) that the output is not cryptographically secure First off: the design ...


403

It typically works like this: Say your password is "baseball". I could simply store it raw, but anyone who gets my database gets the password. So instead I do an SHA1 hash on it, and get this: $ echo -n baseball | sha1sum a2c901c8c6dea98958c219f6f2d038c44dc5d362 Theoretically it's impossible to reverse a SHA1 hash. But go do a google search on that exact ...


376

Diffie-Hellman is a way of generating a shared secret between two people in such a way that the secret can't be seen by observing the communication. That's an important distinction: You're not sharing information during the key exchange, you're creating a key together. This is particularly useful because you can use this technique to create an encryption ...


350

"If lack of encryption allows FBI to catch terrorists, then lack of encryption allows criminals to loot your emails and plunder your bank account." The rational point here is that technology is morally neutral. Encryption does not work differently depending on whether the attacker is morally right and the defender morally wrong, or vice versa. It is all ...


303

I dug out my copy of Applied Cryptography to answer this concerning symmetric crypto, 256 is plenty and probably will be for a long long time. Schneier explains; Longer key lengths are better, but only up to a point. AES will have 128-bit, 192-bit, and 256-bit key lengths. This is far longer than needed for the foreseeable future. In fact, we cannot even ...


234

You can roll your own, but you probably will make a major security mistake if you are not an expert in security/cryptography or have had your scheme analyzed by multiple experts. I'm more willing to bet on an open-source publicly known encryption scheme that's out there for all to see and analyze. More eyes means more likely that the current version doesn'...


231

The reason why you want to avoid implementing cryptographic algorithms yourself is because of side-channel attacks. What is a side-channel? When you communicate with a server, the content of the messages is the "main" channel of communication. However, there are several other ways for you to get information from your communication partner that doesn't ...


166

Right now the question is a bit broader: RSA vs. DSA vs. ECDSA vs. Ed25519. So: A presentation at BlackHat 2013 suggests that significant advances have been made in solving the problems on complexity of which the strength of DSA and some other algorithms is founded, so they can be mathematically broken very soon. Moreover, the attack may be possible (but ...


158

Why do people buy red sport cars ? They do not go faster than sport cars of any other colour... AES comes with three standard key sizes (128, 192 and 256 bits). Many people see this and think that if there are three distinct sizes instead of just one, then there must be some difference, and since the 256-bit version is a bit slower than the 128-bit version (...


158

Diffie-Hellman is a key exchange protocol but does nothing about authentication. There is a high-level, conceptual way to see that. In the world of computer networks and cryptography, all you can see, really, are zeros and ones sent over some wires. Entities can be distinguished from each other only by the zeros and ones that they can or cannot send. Thus, ...


156

You should never send passwords in the clear, nor should you store them in the clear. You should hash them using a slow one-way cryptographic hash such as bcrypt or PBKDF2. If a user forgets their password, you offer them a "reset password" function, which sends a one-time reset link to their account. A scheme such as the following is reasonable: Hash all ...


151

The other answers do an excellent job explaining the maths behind the key exchange. If you'd like a more pictorial representation, nothing beats the excellent paint analogy shown on the Diffie–Hellman key exchange Wikipedia entry: Image is in the public domain


151

As usual, journalism talking about technical subjects tends to be fuzzy about details... Assuming that a true Quantum Computer can be built, then: RSA, and other algorithms which rely on the hardness of integer factorization (e.g. Rabin), are toast. Shor's algorithm factors big integers very efficiently. DSA, Diffie-Hellman ElGamal, and other algorithms ...


139

Use Java keytool to convert from JKS to P12... Export from keytool's proprietary format (called "JKS") to standardized format PKCS #12: keytool -importkeystore \ -srckeystore keystore.jks \ -destkeystore keystore.p12 \ -deststoretype PKCS12 \ -srcalias <jkskeyalias> \ -deststorepass <password> \ -destkeypass <password&...


137

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


116

Because there actually is a cryptographically secure alternative to Math.random(): window.crypto.getRandomValues(typedArray) This allows the developer to use the right tool for the job. If you want to generate pretty pictures or loot drops for your game, use the fast Math.random(). When you need cryptographically secure random numbers, use the more ...


106

Would an 'ideal' HTTPS service only enable TLS 1.0, 1.1 and 1.2 with key-size variants following ciphers? No, an 'ideal' HTTPS service would enable only TLS 1.2 and enable only AEAD (Authenticated Encryption with Associated Data) based cipher suites with SHA-2, 4096 bit DH parameters and 521 bit EC curves of a type that matches your requirements (...


103

In a word: sufficient. This is block-level encryption, so it is filesystem-independent. Ubuntu's transparent encryption is done through dm-crypt using LUKS as the key setup. The built-in default for cryptsetup versions before 1.6.0 is aes-cbc-essiv:sha256 with 256-bit keys. The default for 1.6.0 and after (released 14-Jan-2013) is aes-xts-plain64:sha256 ...


99

Your most recent edit indicates that your pictures are procedurally-generated, so your key size will therefore be bounded by the amount of state required to generate an image. Yours seem to be parameterized by four floats for the initial conditions (and fixed output image size, camera location, point light location, convergence conditions, etc). Those 128-...


92

Producing SHA-1 collisions is not that easy. It seems reasonable that the attack with has been described on SHA-1 really works with an average cost of 261, much faster than the generic birthday attack (which is in 280), but still quite difficult (doable, but expensive). That being said, we do not really know what makes hash functions resistant (see for ...


89

This is a serious problem in password-management. The first problem here is the way they managed his key in their source code. SnapChat states that they send the photos encrypted over internet, and it is true after all, but they are using a "pre-shared" key to encrypt this data (badly using also AES in ECB mode) so, every user around the planet has the key ...


87

Don't roll your own crypto! From a purely cryptographic point of view, any length-preserving bijective function cannot reduce security. In fact, even the identity function, defined as f(x) = x, will not reduce security, assuming the keys used for the standard cipher and your homebrew cipher are mutually independent. The only possible way it could reduce ...


87

exactly one message maps to a given hash This is not possible due to the pigeonhole principle. As long as the input message to the hash function can be larger than the hash itself, it is guaranteed that some messages collide with each other and map to the same hash. This is normal and is not a problem for the security of hashes by itself. You only need to ...


85

The side channel attacks mentioned are a big thing. I would generalize it a bit more. Your crypto library is very high risk/high difficulty code. This is often the library that is trusted to protect the rest of an otherwise soft system. Mistakes here can easily be millions of dollars. Worse, you often have to fight your own compiler. The trusted ...


83

ECDHE suites use elliptic curve diffie-hellman key exchange, where DHE suites use normal diffie-hellman. This exchange is signed with RSA, in the same way in both cases. The main advantage of ECDHE is that it is significantly faster than DHE. This blog article talks a bit about the performance of ECDHE vs. DHE in the context of SSL.


81

I would take their argument and replace "cryptography" with "locks and keys on our houses" and see if they still agree: If more terrorists and criminals would be caught by not having locks and keys on our houses, I would not blame warrantless searches by government and companies in our homes.


80

Because this is a fundamental principle of information theory. If a machine can decrypt a piece of information and keep it for ten seconds, it can decrypt it and keep it forever. Any attempt to disguise this is simply smoke and mirrors.


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