Hot answers tagged

73

The reason that salts are used is that people tend to choose the same passwords, and not at all randomly. Many used passwords out there are short real words, to make it easy to remember, but this also enables for an attack. As you may know, passwords are generally not stored in cleartext, but rather hashed. If you are unsure of the purpose of a hash-...


13

There are a number of considerations here, I'll try to lay them out one at a time for ease of following: What must the site do with the data? Oftentimes, we ask web sites to do things on our behalf when we are not actually visiting them. For example, I may want crypto.SE to email me when there are responses to this post. The site could not do that ...


10

Yes, scrypt achieves this. Scrypt has a variable-length output, so just generate as much output as you need. For instance, you can ask it for 256 bits of output, then use the first 128 bits for one key and the second 128 bits for the other key. While PBKDF2 also has a variable-length output, I do not recommend that you use it in the same way. It has a ...


8

It sounds like you're using a password-based key derivation function that accepts an optional salt input to convert a passphrase into an encryption key, which you then use to encrypt messages with a block cipher mode (or possibly some other type of stream cipher) that takes an IV or a nonce, and you want to know whether it's necessary to provide a salt to ...


6

You are using a Vernam-encryption (simple XOR), as for the one-time pad. The general principle for Vernam is that it is perfectly secure as long as you never reuse the same key for more than one message, and gets utterly broken as soon as it is reused even once (this is the "two-time pad"). The key here is the hashed password, the message the key. If one ...


6

Here are some hints on how it's done on Mega: The password provided is passed through a KDF to derive a key, that is used to en-/decrypt the master key (later provided by the server through an API call). To bring it down to the crucial bits: The KDF applies $2^{16}$ rounds of AES-128 with it. The details can be found in the function prepare_key() of the ...


6

Don't bother with changing the actual cipher algorithm. Read about Kerckhoffs's principle: you should only change things like the key and the IV, not the actual algorithm. In order to test your avalanche, flip one bit in your key. That should change about half the bits in your output. For cipher design, Applied Cryptography has already been suggested. ...


5

See “format-preserving encryption” at WikiPedia. Depending on the size of the message space, one can get such a scheme by: sorting pseudorandom values, see section 4.1 of “Format preserving encryption”, or using this arbitrary-size scheme described in “Perfect Block Ciphers With Small Blocks”, or using swap-or-not as described in “An Enciphering Scheme ...


5

Both scrypt and pbkdf2 have variable length outputs, and each bit of the output is effectively independent on every other bit. So, one obvious way would be just to ask for enough output for both keys. For example, if the two keys are each 128 bits, then ask scrypt (or pbkdf2) for 256 bits of output; use the first 128 bits as the first key, and the second ...


5

Can you help me understand what a cryptographic “salt” is? In the context of password creation, a "salt" is data (random or otherwise) added to a hash function in order to make the hashed output of a password harder to crack. When might I need to use it? Always. Why should or should I not use it? You should always use a salt value with your ...


5

Short answer: Use bcrypt. Long answer: First, "hashing a password with the password" is an undefined statement. Regardless, you are well into "inventing your own crypto" territory. Assuming you mean something along the lines of SHA-256(password + password), this is a phenomenally bad password digesting scheme. Being unsalted, your approach is vulnerable to ...


5

One option would be to generate a random key, split it using Shamir's secret sharing, then encrypt each of the split parts individually under a key derived from each user's password. So for example: key = read from os.urandom() d1,d2,...d5 = split(key=key,n=5,k=3) e1 = encrypt(d1, KDF(PW1)), e2 = encrypt(d2, KDF(PW2))... key can then be derived from all ...


4

Using the password itself (or anything similar predictable) instead of an independent random value as the salt denies the whole benefit of salt: Same passwords (passphrases) give now the same key, instead a different one. So, if two users happen to choose the same favorite image as their password, they get the same key, and thus an attacker can use this ...


4

I'm going to attempt to answer a part of your question that has so far been neglected: when I might need to use it and why I should/should not use it. The short answer is that, as an amateur, you should not be using cryptography at a level that requires dealing with salts directly. For instance, the bcrypt password hashing algorithm uses salts ...


4

You can use the ecryptfs-add-passphrase command to add a passphrase to your kernel keyring, which will also print the signatures (hashes) to standard out. Once you've added a passphrase to the keyring, you might want to clear it, using the keyctl command. eCryptfs uses a PBKDF2-like, key strengthening algorithm of 65536 rounds of SHA512. (Disclosure: I am ...


4

I don't think it is a good idea, for two main reasons. Firstly, you are basing your security on the obscurity of a parameter that was not designed initially for being secret, which is a risky practice. It is similar to hiding the salt. Secondly, following your example, you may in principle think that a random number of iterations between 10 and 100,000 is ...


4

A possible solution: When encrypting, ask the user to enter a password $p$. Produce a salt $s$. Enumerate the password with all tolerable typos to get array $a$. For each $a_i$, calculate $b_i=hash(a_i)$ to get array $b$. In the output file, write the salt. Generate a random key $k$. And for each $b_i$, write the pair $(hash(b_i||s),b_i\oplus k)$. Write the ...


3

I think what you are looking for is a Password-Based Key Derivation Function (PBKDF). You can take a moderately strong password, like 12-14 random letters and numbers (no dictionary words though!), and throw it into the PBKDF function together with some other parameters, e.g. salt, number of iterations and the desired key length. After that you have a ...


3

It is common that the attacker has at least as fast platform as somebody generating the key. Thus, brute force attacker can test all 4 digit PINs in 1000 seconds or 17 minutes (based on 100 ms seconds mentioned in the question). BTW, it is fairly common to use larger iteration counts than minimum of 1000 and longer times (like anything that takes 1s to ...


3

The part of this answer that talks about key storage is at the end, the first part is about implementing a cascade. There are 2 main methods for cascading block ciphers, inside of the mode and outside of the mode. Within the encryption you have your mode of operation, and you have your block cipher cascade. The first cipher in the cascade will be considered ...


3

There's no advantage to padding short passwords with a (non-secret) constant. It doesn't make the password hashes any harder to crack by brute force guesswork: if an attacker can program a computer to try common passwords like abc, 123, swordfish, etc. (and they can, with very little effort), they can also just as easily make it try ...


3

It is a random number that is needed to access the encrypted data, along with the password. If an attacker does not know the password, and is trying to guess it with a brute-force attack, then every password he tries has to be tried with each salt value. So, for a one-bit salt (0 or 1), this makes the encryption twice as hard to break in this way. A two ...


3

To begin with, I see four potential problems with your key file. The work factor (8) is probably too low. If we presume you pick your pass phrase by selecting $c$ words at random from a list of $2^{13}$ distinct words (e.g. correct horse battery staple) you get a pass phrase with $13c$ bits of entropy. (AFAIK the dictionary used by Diceware only barely ...


3

Simplest is to use a stream cipher. You will not get authentication, but that would be impossible with format preserving encryption anyway. Does the encrypted string need have the same character set (e.g. hex or base 64)? In that case: Transform to binary. Encrypt with stream cipher. Transform back. AES CTR would work, as would any other stream cipher. ...


3

The problem is almost exactly the same as in password based key derivation, so you could use a similar solution. Derive a master secret from your password and a unique salt using e.g. PBKDF2 or scrypt: $S_m = PBKDF(p, s)$. Derive a site-specific secret from the master using e.g. HKDF and the site URL: $S_u = HKDF(S_m, u)$. Turn the site secret into a ...


3

Password-based encryption uses a hash function to derive a key from a password and that is the only use of a hash function. PBEWithMD5AndDES itself doesn't provide any authentication (includes integrity) and only uses MD5 for key derivation. If you want authentication, then you can still use PBEWithMD5AndDES, but you then would have to derive a MAC key from ...


3

Yes, the principle to use a common password and a unique salt per file with a key derivation function is a good and acceptable practice, as you generate the salt randomly and with the right size. The uniqueness of the salt guarantees a different password per file (actually one password per salt, so: do not reuse a salt, use a csprng). You forgot to mention (...


3

In the context of most Password Managers that use encryption, you will generate a Master Data Encryption Key (MDEK) which will serve to encrypt all the passwords and the user's password would be the Key Encrypting Key (KEK) to encrypt the MDEK. This way, the MDEK stays the same when you change your Master Password derived KEK that wraps the MDEK.


2

I don't know what Mega is doing. They haven't published a design document that describes how their system addresses these threats. That's irresponsible on their part, and it doesn't invite trust. Cryptographers have already criticized Mega for sloppy engineering, and researchers have found a bunch of security problems, vulnerabilities, and design issues. ...


2

Here's a possible scenario: 1) Your password is put through a slow KDF such as Scrypt. The output of Scrypt can be configured to take a long time to calculate, and as such, can mitigate the risk of brute-forcing passwords. See here. 2) The output length of Scrypt is also configurable. So assume that half of the output becomes the encryption key for ...



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