# Tag Info

55

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

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

5

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

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

5

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

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

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

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

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

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

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

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

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

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

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

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

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

2

What you are looking for is a Pseudo Random Function that should be indistinguishable from uniform, even if the key material that is passed to it is not. One potential problem with your scheme is that the AES key schedule is not particularly good at extracting the entropy from keys that are not selected (pseudo-)randomly, such as passwords and pass-phrases. ...

2

Your idea is no stronger than simply having a common shared password $P_1$ from which the symmetric encryption key is derived. If Alice encrypts a message with Bob's hashed password, even if someone knows the shared password, only Bob can decrypt the message You assumed the hash of Bob's password – $H(B_1)$ – is public, so if Eve knows both it and the ...

2

If you want to keep the crypto simple and mostly on the server side (which may be a good choice e.g. if you're developing a web service), you could use the following scheme: To log in, the client sends the password $P$ to the server in clear, preferably over a secure channel (e.g. HTTPS). The server derives a "master key" $K_0$ from $P$ using a ...

2

I don't see where the method implies a PIN is good practice? This is just a wrapper function for a key derivation function, and the variable names chosen to say "This is the one that contains the not-very-random-data". Obviously more entropy the passphraseOrPin variable has the better, but it might just be that for use-ability's sake a designer only uses a ...

2

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

2

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

2

Generate key-pair Generate random salt, hash password with proper password hash (scrypt or PBKDF2) to derive a master key. Use HKDF to derive one login key and one encryption key from master key Encrypt private key with encryption key from previous step Upload it to server, download only possible by proving possession of login key (either send over SSL, or ...

2

Does it mean that a binary keyfile of more than 64 random bytes (each having 8 bits of entropy?) is useless with PBKDF2 and a hash of 512 bits like SHA-512? The cost of testing all the hashes directly being cheaper than testing all the keyfiles. Yes, it does. After 128 to about 256 bits security the amount of security provided by the bits alone doesn't ...

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

2

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

2

Is it subject to some class of attacks or is it just a really bad crypto nightmare which is only subject to brute-force attacks? You are calculating PBKDF2 twice, which takes twice as long. An attacker doing a brute force or dictionary attack only needs to calculate one of them to verify his guesses. That means you are making attacks twice as easy as ...

2

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

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