27

If we take two password strings of different length and attempt to bruteforce match them, it is obvious that the longer one will take longer to crack on average. Actually, that might be obvious to you, but it's not true. A brute force search is one where an attacker has a long list of passwords, and tries them in succession. Now, if the attacker is at all ...


24

If a computer is doing the selection of PIN numbers, then you would be very lucky indeed to guess a PIN in three times. The entropy - assuming that all numbers are valid - is of course $\log_2{10^8} \approx 26.57$ bits. The chances of guessing the PIN correctly in 3 tries is $$1 - \frac{x-1}{x} \cdot \frac{x - 2}{x-1} \cdot \frac{x-3}{x-2} = 1 - \frac{x-3}{...


19

There's a 2013 article in Ars Technica that refutes the notion that long passwords are necessarily hard to crack. It details how security researchers Kevin Young and Josh Dustin turned to text from Wikipedia and Project Gutenberg as a seed to come up with longer and longer phrases to try in their password crackers, and managed to crack some impressively ...


17

Though quantum computers fit the requirements, I'm not sure they are the best option. A general purpose quantum computer capable of attacking modern encryption (RSA, AES) would have serious ramifications on society. It's not only applicable to this one cipher you are breaking. Does it have to be the superior computing resources which gives the good guys the ...


9

The Bitcoin Bip-39 dictionary with 2048 words can create $\approx 2^{263}$-entropy by tossing the coin 256 times to choose the words randomly. The random bits are converted into 24 11-bit blocks and every block is mapped into one of the 2048 words by ID. Since the random choice allows repetition, we need $n^r$ not $P(n,r)$; $$2048^{24} \approx 2....


7

The chance to guess right is just $$\frac{3}{10^x}$$ where in your case, $x$ is $8$. You could write it as $$1-\frac {99999999}{100000000}\cdot\frac {99999998}{99999999}\cdot\frac {99999997}{99999998}=1-\frac {99999997}{100000000}=\frac 3{100000000}$$ To simplify it, just imagine a one digit PIN. You have ten possibilities, from 0 to 9. With three tries, ...


7

9 lower case letters with standard English alphabet make around 40-bit direct search this is very low password entropy. This is quite achievable even you use high iteration numbers like 200000 iterations for the HMAC-SHA-256. 200000 makes $\approx 2^{18}$ so in total $\approx 2^{58}$ Even public laboratories in the USA, like Oak Ridge Summit, can achieve ...


6

A cryptographic key is a string of bits. For example, AES-128 uses 128 bits, each one of them being either 0 or 1. To be able to encrypt or decrypt, each one of those 128 bits must be set correctly. This key is the input to the encryption algorithm. For AES-128 it has to be exactly 128 bits - not more nor less. For humans, remembering 128 bits (= 16 bytes) ...


6

Regarding your understanding You mostly have things right, but not completely. a password is a (preferably) mnemonic string that is fed into a function that generates a much longer and complex string that nobody knows, the user included. The encryption key is what is actually used to encrypt and decrypt a file. This is true apart from “preferably mnemonic”....


6

Party B will eventually succeed; still, to keep a modicum of suspense up, it must still be possible for them to fail An approach that will allow party B to succeed nonetheless To me the obvious solution is strategy and HUMINT. With algorithms at the time, say bcrypt and AES-256, plus a high entropy password, party A would spend eternity either attacking ...


5

You are correct: generally it is required to synchronize or otherwise synchronize information if you want to use a password based key derivation function (PBKDF) for sending messages. That doesn't mean that using a password on the client side a derived key on the server side doesn't have advantages: the password isn't stored on the server side, so an ...


5

PIN check is bound to rely on trusted device or security by obscurity. If a 4-digit Personal Identification Number is stored and validated in an device (possibly composite, like combination of server and mobile device) of known construction, and an adversary acquires/extracts all the data stored in the device, including the (possibly encrypted or hashed) ...


5

Summarizing the question: I can have up to $v$ valid tokens at any point in time in the system, how much more entropy do my tokens need to have compared to "regular" password systems? In addition to regular password entropy, $\log_2(v)$ bit extra is enough if the number of online attempts $a$ that an attacker can make is unchanged. That amount of ...


5

It's nice to see SciFi authors consulting professionals for technical viability problems. I've got something on my mind for you to consider. This is what I need: An algorithm such that, if you encrypt a file with it using a high-entropy password, is beyond any brute-force attempts using known methods and tech. There was a joke a while back in the NIST Post-...


4

Yes, 7-8 words selected truly at random make a strong password. First we should consider what is a strong password, we measure the strength of a method of generating passwords by how much entropy is in it. The XKCD method https://xkcd.com/936/ uses 4 random commom words and has 44 bits of entropy. This is considered a reasonable compromise if you want a ...


4

The attacker wouldn't need to know the padding pattern, consider the following The padding is done client side Attacker scripts and posts directly to the server The attacker reverse engineers the client front end and adds that padding to the script they are writing to post requests to the server, the complexity generated by appending the padding has been ...


4

Is the salt format moot because the entropy of 32 binary bytes is the same as 42.7 base64 characters, or is one format really a better choice? TLDR: moot, for the reason stated, as long as the whole thing is hashed and not otherwise used, and the hash used is secure, and the iterated hash construction on top of that is otherwise sound. The fear that ...


4

Would there be any additional benefit to this scheme? Not really; password hashing is storing the hashed password in this form: $$H( \text{password}, \text{salt} )$$ where $H$ is some hard-to-compute hash function. What you are suggesting is to replace this with: $$H( \text{password}, D( \text{password}, \text{encrypted_salt}) )$$ (where $D$ is the ...


4

The symmetric encryption algorithms require keys with good entropy. Usually, humans tend to have passwords with bad entropy then they are crackable There are well-known cracker programs like John the Ripper and hashcat, and rainbow tables. Today, we have better password mechanisms like Dicewire so that the entropy of the password can be much longer. In any ...


3

KDFs are better used for offline protocols. What is often used for your second case are Key-agreement protocols. As far I know, there's no secure way of using KDFs in such interactive context where both parties need to know the key a priori. Key-agreement protocols make it feasible to compute a shared-secret (the encryption/decryption key) on demand - both ...


3

Generally you don't want to switch algorithms in cryptography. You'd have to deal with different workloads. Furthermore, the choice of algorithm would be just another salt, if a tiny one. However, your approach doesn't disallow the building of 5 separate rainbow tables. So the reason for a salt isn't met. It is unclear why you would not be able to use a ...


3

Modern FileVault is a relatively slow hash. hashcat supports attacking FileVault 2 hashes as mode 16700. As an example of real-world attack capability, if a seven-character password were truly randomly generated, then it would take a little more than seven years to fully exhaust on a rig with six reasonably fast GPUs: $ hashcat -a 3 -m 16700 -w 4 filevault....


3

If you use an augmented PAKE (such as AuCPace or Opaque), the server never gets a copy of the password in the first place. Hence, to update the password, you would reregister with the new password, but the reregistration process wouldn't involve sending the password. If you use a balanced PAKE (such as Spake-2), well, the server does need the password. ...


3

Like Ray, I'd like to point out that if the PINs are not chosen randomly but selected by humans and there is no rejection of the easiest pins, the same rules as for passwords apply: some are very, very, very common. This analysis of 4-digit pins shows that 3 tries will allow you to break over 18% of 4-digit pins, not the 0.03% you would expect from the ...


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

Specifically, is it safe to re-use the same nonce for decryption an indefinite amount of times, if you only use it once for encryption? Indeed, all good security definitions (under which ciphers are proven secure) will place no restrictions on the input of the decryption algorithm. The intution behind this is that the the input to the encryption algorithm ...


3

No for this scenario where the message is statically sized, using a HMAC is not required. You can use a sufficiently strong hash such as SHA-2 or SHA-3 instead if you must. That said, it would probably be more neat to use a HMAC or even KDF. The advantage is that these algorithms do take input keying material as a separate parameter. This might be ...


2

Only randomly generated components matter for passwords/passphrases. 6 randomly generated symbols: lower/uppercase letters and numbers. You have 26+26+10 possible characters, so 62. The entropy of a password is $L\log_{2}N$, where $N$ is the number of possible symbols and $L$ is the number of symbols in the password. So you have $6\log_{2}62=35$ bits ...


2

Using the HKDF algorithm would work: prk = HKDF-EXTRACT(salt, master_key) Key1 = HKDF-EXPAND(prk, "info 1", digest_len) Key2 = HKDF-EXPAND(prk, "info 2", digest_len) This creates two keys that are generated from the master key, but given Key1, someone else wouldn't be able to generate Key2, as they don't know the master key.


2

According to the MySQL Server Blog, it is: The advantage of mysql_native_password is that it support challenge-response mechanism which is very quick and does not require encrypted connection. However, mysql_native_password relies on SHA1 algorithm and NIST has suggested to stop using it. caching_sha2_password tries to combine the best of both worlds....


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