Tag Info

Hot answers tagged

30

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

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


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


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

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


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

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

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


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

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


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


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

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


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

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


1

I think OP doesn't know much about crypto we can't just say use this use that without proper explanation. I'm not certain but I think I understand what OP really mean. While OP doesn't know what he should asked; others also answer as everything the question imply. OP said 10 characters not 10 bytes that why Mr.Demer came up with format-preserving ...


1

It is important to make sure that password based key derivation takes place before passphrase correctness is checked. Otherwise, possible attacker can choose if they attack against passphrase correctness check or pbkdf function. (Appears ok on the both functions.) PasswordSafe In case of very high entropy key, it theoretically could be possible that for ...


1

The random number generation routine must have supreme randomness, special care should be taken to ensure this. The larger concern is the decryption of the keyfile should in no way reveal the key to even authorized users. The password entropy concerns have been well voiced. Depending on the frequency of key changes, you may require > 112 bits of entropy. ...


1

Search for passwords on IT Security and you will find tons of advice on how to store passwords, and how not to. Your scheme is not a good method for hashing passwords: it is a fast hash, it lacks any salt, and it unnecessarily limits the password length. People have studied this at great length: before trying to re-invent the wheel, I suggest you read up ...



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