# Tag Info

6

I don't believe that looking at the diceware phrase is very helpful. Instead, look at it this way; there are $7776^7 \approx 2^{90.47}$ possible 7 word diceware phrases, and diceware will select one of those possibilities uniformly. That means that the probability that one specific phrase is selected is at most $2^{-90.47}$. Or, in other words, if someone ...

6

Users have a habit of choosing passwords badly so that they can be guessed much more easily than cryptographic keys, requiring (say) only a trillion ($10^{12} \approx 2^{40}$) guesses on average instead of a duodecillion ($10^{39} \approx 2^{128}$, or thousand sextillion in the long scale) guesses on average. Users also have a habit of reusing passwords ...

6

Well, the best answer I can think of is by referring you to Scott Aaronson's wonderful blog. Quoting the very header of the blog: If you take just one piece of information from this blog: Quantum computers would not solve hard search problems instantaneously by simply trying all the possible solutions at once. So no, a quantum computer would not try ...

5

Not every company hashes passwords properly and not everyone chooses secure passwords. If you hash them poorly (i.e. if you do not use a password hash with salt, and simply use SHA-256), then you can use a dictionary attack where you hash a list of common passwords and compare them to the leaked hashes and try to find any matches. This way, you can "invert" ...

4

It seems that there are many tools that support strong encryption algorithms, such as AES256, but finding one with a good key stretching function is not so easy. The two standard tools are OpenSSL and GnuPG. However, when it comes to key stretching, OpenSSL 1.1 uses PBKDF2 and GnuPG uses Iterated and Salted S2k, and both are not very resilient to brute-force ...

4

however something that strikes me as counter intuitive is how PBKDF can somehow "stretch" the entropy of a supplied password to generate crypto graphically secure keys. PBKDF2 and other slow KDFs don't increase the actual entropy, but increase its effective entropy. That is, a KDF can make a weaker password with relatively low entropy take as long to attack ...

3

Here are a few games we can play: I roll a die 50 times. I write down the results as 1, 2, 3, 4, 5, or 6. You try to guess what I wrote down. I roll a die 50 times. I write down the results as one, two, three, four, five, six. You try to guess what I wrote down. I roll a pair dice, 25 times. I write down the results as 11, 12, …, 16, 21, 22, 23, …, 66. ...

3

Password hashing does not increase entropy, no deterministic algorithm can do that. The purpose of a KDF is to increase the difficulty of a brute-force (or dictionary) attack by making the testing of candidate passwords slow. For example, if your passwords are drawn from a distribution with say 48 bits of entropy then with a reasonable computer one could ...

3

Considering quantum computing to break passwords in the online setup would be nonsense. In that setup, passwords are sent to a classical system testing the password. That seems to be the question's scenario. In the offline setup, the information that allows testing if a password is accepted or not is assumed to have leaked to the attacker (e.g. because the ...

3

This can be done with a cryptographic protocol called Password-Authenticated Key Exchange (PAKE). It comes in a few flavors: Plain PAKE is a good fit for peer-to-peer connections. Both participants know the password in the clear, and use it as input to the PAKE protocol. If they both agree on the password, then they establish a shared secret key, safe from ...

3

Let call a user's Master Key for AES as $\mathit{MK}_u$ and generated as; $$\mathit{MK}_u = \operatorname{PBKDF2}(\mathit{passwd}_u, \mathit{salt}, \mathit{Iteration})$$ where $\mathit{Iteration}$ between 40K to 100K 1. To salt and then hash the master key (once). The resulting salt and hash are stored somewhere - for instance in a DB. Later on, when ...

3

It seems you are using a password based key derivation function (PBKDF2) to derive a password from information (the service name) and a key. That's kind of backwards, but given that there are often no Key Based Key Derivation Functions(KBKDFs) such as HKDF available, I'd say that it is acceptable practice. You might however use a single iteration, assuming ...

2

It is my understanding that a KDF adds entropy, whereas a hash loses information. No deterministic process can add entropy. If the same input always produces the same output then the entropy associated with the output cannot be more than the entropy of the input. The confusion probably comes from the practice of using password stretching to compensate for ...

2

The calculation is correct for the given information source. I''m providing a second answer to emphasize that it's only meaningful to talk about the entropy of "information source" - that is mechanism from which data is generated. Since the example given is a rule for creating passwords (insecure ones), it fits to discuss the entropy. Had it been a ...

2

If the 256-bit AES key is only used to encrypt the 256-bit password, then I don't think you even need AES at all because a simple OTP can do the work. You may want to use AES if considering a computationally bounded adversary that is able to know some plaintext-ciphertext pairs. OTP has perfect secrecy for one-time use so no adversary (with unlimited ...

2

What you're after is fundamentally impossible. Password hashing algorithms are inherently slow. They're designed to be slow even on a computer. Otherwise they would not serve their purpose, which is to make brute force search infeasible. A fast password hash is a broken password hash. You cannot possibly get anywhere near the requisite level of slowness with ...

2

It is likely secure, yes, when it comes to SHA-1. The S2K function, as you mention, simply repeatedly inputs the 8-byte salt and encoded passphrase into the ongoing hash function until a certain number of bytes has been processed (the work factor for this function). Then it produces a key that is smaller than the hash output size. Now this output is an ...

2

It kind of makes sense, but there are some hairy details. To use a password as a key you need a password based key derivation function or PBKDF, not just any KDF. Otherwise the adversary can try and guess the password and try to decrypt anything you encrypted with it. Generally that would take just one additional block decrypt, so that's generally a fast ...

2

But the attacker trying to break it as a normal password could assume that it is made up of English words and then they'd know that some letters and combinations of letters are more common. They could try this, but they would be stupid to try this, because there are many fewer $N$-word diceware passwords than $M$-letter strings of English letters of the ...

2

For a PIN of length 9, you have exactly 10^9 = 1000000000 combinations (which can be brute-forced by a computer in less than one second). That's 29.9 bits of entropy. For a PIN of at most 9 digits, you have exactly 10^9 + 10^8 + ... + 10^1 = 1111111110 combinations, which is not that greater than the previous answer. That's 30.0 bits of entropy.

2

I think there are two things that are confusing you. Consider sequences of n digits, e.g. 12946, and sequences of n words-for-digits, e.g. one two nine four six. The former have much more entropy per character, in that (for example) the first digit (1) tells you nothing about the second (2) whereas the first letter (o) sometimes completely determines the ...

1

Using crypto_secretstream that should be fine. It generates a random nonce for each message. Reusing a key in that context is fine. Original answer, before edit follows: Yes, that's bad. You have to use a unique IV/nonce for each document. A stream cipher, such as ChaCha, which is combined with the plaintext using XOR reveals the keystream to anyone who ...

1

The simplest solution to this would be to encrypt Bob's pass phrase under Alice's pass phrase. In particular the following steps would be carried out for that: Generate a salted password hash (using e.g. Argon2 or bcrypt) from Alice's pass phrase, call it $SK$ Use $SK$ to encrypt Bob's pass phrase symmetrically, e.g. using AES-GCM If you want to be fancy ...

1

To get "nicer" passwords, whatever that means, the suggestions are typically: … use a selection method but be aware you lose entropy (e.g. pick $1$ out of $16$ passwords at the cost of $4$ bits of entropy) What you are doing is effectively ‘a selection method’ (more commonly known in the literature as rejection sampling) with a bound on the ...

1

I thought of it because nowadays we do not have computational power to break those hashes, so how can a criminal use those hashes against the users? Breaking a hash algorithm requires a pre-image, second pre-image, or collision attack that is cheaper than brute force. (For full or partial outputs.) More generally, a broken algorithm is any algorithm for ...

1

Passwords that contain dictionary words are certainly not as secure as randomized strings with the same length. According to the Oxford dictionary: The Second Edition of the 20-volume Oxford English Dictionary, published in 1989, contains full entries for 171,476 words in current use However, English as spoken has around 30,000 if I remember correctly, ...

1

What you are describing is a one-time-pad. If the password was encrypted with a 256 bit key and the resulting ciphertext was acquired by the attacker then he would produce all $2^{256}$ possible plaintexts (including the correct one) but there would be no way to distinguish which one is correct. However no one uses OTP in practice because the key has to be ...

1

It's generally not a good idea to store passwords of any kind in a database that's not secure, let alone a database that's intended to be publicly available. Is it secure? If you don't care about tampering and wrong entries in the database then I guess this setup is okay. Bcrypt already incorporates a salt to prevent rainbow attacks, so all passwords ...

1

Regardless of the password, encryption, etc., you have another possible issue. You will need to make sure that, when you receive the decrypted JSON object(s), you again validate them to make sure they have not been tampered with while in the possession of the user. Whether such an attack is worth doing will depend on the application (think game server, ...

1

This answer proposes a solution based on local storage and local encryption. The data of the forms that the user enters: Can be locally encrypted whenever the user wants to save... The encrypted file(s) can be stored locally, if you want to store it to, you can transfer a copy to your server The encrypted file(s) can be decrypted locally and restored into ...

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