# Tag Info

7

There is nothing related to passwords in AES. AES uses 128-bit keys, i.e. sequences of 128 bits. How you come up with such a key is out of scope of AES. In some contexts, you want to generate these 128 bits in a deterministic way from a password (and possibly some publicly known contextual data, like a "salt"); this is a job for password hashing. In other ...

5

If I understand correctly, you want a function that for each input string $p$ assigns a permutation over an alphabet $L$. If the number of elements in $L$ is small enough, the permutation set $P(L)$ will be enumerable. More precisely, $|P(L)| = |L|!$. There exists a surjective function $f:\{0,1\}^k \to P(L)$ that for each bit string $s$ of length $k$ ...

5

I agree with the comments that SHA-256 should be fine here. However, if you already use HMAC-SHA-256 for PBKDF2, you could use HKDF Expand, which despite its name is defined even for output lengths shorter than input. In your case the output would be simply: $$\operatorname{HMAC-SHA-256}(\text{key}, \text{info} || \text{0x01}),$$ where 'info' is an ...

4

Using PBKDF2/Bcrypt/Scrypt might be the least-bad way, but that doesn't mean it's a good way. If your passphrase is puppies, it doesn't matter whether you use PBKDF2, Bcrypt, or Scrypt: you've got serious problems. If someone tries to crack your key, you're going to be toast: your key will be cracked within minutes. Bottom line: this sounds like a bad ...

4

Given a EC public key, can a different, but plausible and functional private key be derived to match the public key? No, a public key will correspond to only one private key (with one minor exception, which I will explain below). With Elliptic Curve systems, the private key is an integer $d$ between 1 and $q$ (the order the generator point $G$), and ...

4

Of course you can - but as to whether or not it's a practical or advisable idea, I don't think so. It's not really prudent to implement crypto systems/protocols and assume that they'll be fine in 10 years. Cryptography is a dynamic field that changes rapidly; algorithms get broken, hardware improves, governments try to undermine the field, and attacks only ...

4

As far as I know (which, admittedly, might be limited; I do not claim to possess encyclopedic knowledge of attacks on KDFs), there are no known practical attacks against KDF1 or KDF2 (which are also mentioned on this page, following ISO-18033-2) when instantiated with a secure hash function. Regarding the relative security of these KDFs vs. HMAC-based KDFs ...

4

It is my understanding that a KDF adds entropy, whereas a hash loses information. Password Based KDFs can be seen as hash functions (or families of hash functions, depending on your definition), just ones with a lot of complexity. It is sometimes said that they "add entropy" but that usually means either they combine entropy from a salt into the ...

3

HMAC nor a KDF is needed here. As long as you always use a constant size key and "tag" (generally called a nonce, as in number-used-once) you can simply use a secure hash function, like SHA-256. My suggestion is to drop keeping track of the tags sent so far - this administration is bound to fail at some point. Instead, generate a 32 byte random number. This ...

3

You want a pair of functions $(f_1,f_2)$ from a set $S$ of possible passphrases to a key set $K$, that is $f_1,f_2: S \rightarrow K$. The functions are public, in the sense that they can be computed by anyone. Your security goal is that the cost of finding $f_2(pw)$, knowing $f_1(pw)$, should be roughly as expensive as finding $f_2(pw)$ by searching for ...

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

One of the advantages of schemes like scrypt and bcrypt is that they are designed to be "hard" to brute-force. That is, the actual guts of the algorithm are designed to continuously use something that is difficult for a specialized implementation to speed up. For example, scrypt is based on sequential memory-hard operations, which makes sequential memory ...

3

Of course it's possible; all you need is take your cryptographically secure input, feed it as the key to a CSRNG, and then use the CSRNG output as the source of randomness to an RSA key generation algorithm. For a concrete example, there are several such key generation methods in FIPS 186-3, with the cryptographically secure input being the 'seed' (and you ...

3

1. To clarify: The critical time period here is one year (after wich the certs are changed). With the cracked RSA key the attacker can decrypt the traffic and do nan-in-the-middle attacks, posing as a valid hardware device. Let us take the numbers determined by experts. In their paper on cracking the 768-bit RSA key the researchers state that they needed ...

2

I'd still go with HKDF. Since you already have a good uniform master key, you can skip the extraction step. So HKDF simply becomes HMAC-SHA-2(masterKey, info+\x01) I'd start info with a string identifying your use, and add the user specific information after that. Your system should be secure as well as long as you only produce a single block of output. ...

2

Okay, for key derivation in the browser you will be using third party libs. If you want to be the absolute top of the line then scrypt (potential lib to consider) is your best bet with a medium to high work factor based on what your users are going to be using. Bcrypt works but is not memory hard so take that into consideration. (Even 5MB of memory usage ...

2

There is something off in your setup: You care about precomputation and dictionary attacks. You assume a password like puppies. You didn't mention any other kind of secret. More formally: You didn't state an attack model. What access does the attacker have? Is there some kind of secure data storage? Are any other encryption schemes useable? To be honest, ...

2

To begin with, we have to assume your deterministic random bit generator is adequate for generating practically indefinite bit sequences given a single seed, and that your prime generation algorithm is such that it will always output a prime eventually, given any such indefinite pseudo random bit sequence. Obviously, a 2048 bit two-prime RSA modulus can't ...

2

scrypt uses PBKDF2 internally, so it's absolutely crucial to prevent nasty interactions. My suggestion would be a simpler scheme (using simplified syntax): $k = \mathrm{scrypt}(key, salt || 0x0) \oplus \mathrm{PBKDF2}(key, salt || 0x1)$ This does exactly what you want - that is, the output key has exactly the strength of the stronger of the two, without ...

2

This is not a good approach. The correct number of iterations to use for PBKDF2 is "as many as you can tolerate". This number is more or less fixed for a given piece of hardware (assuming it isn't overloaded). The kind of calculation you propose is useful for determining if you are meeting an effective minimum number of iterations. The appropriate way to ...

2

GPG implements the OpenPGP standard RFC 4880, so it implements the String-to-Key Specifiers. 3.7. String-to-Key (S2K) Specifiers String-to-key (S2K) specifiers are used to convert passphrase strings into symmetric-key encryption/decryption keys. They are used in two places, currently: to encrypt the secret part of private keys in the ...

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

It's best practice to use the KBKDF to generate separate key material for validation as well as for generating the key used for encryption using a different input or counter of each key. If you do apply a KBKDF for each key / IV (using different ID's/counters for each) then you should not have any concern leaking any information. These KBKDF's are plenty ...

2

Short: In some simple cases, hash could be adequate. However, HKDF is intended to be a generic construct you can commonly apply for needs requiring Extract-Expand (such as when you have a shared secret agreed using DH or ECDH). It aims to be largely compatible with existing practices and thus makes it easy to apply the same pattern to multiple uses. It ...

2

You could 1. generate a key from the password, 2. seed a deterministic random number generator from the key, 3. use the random number to generate a permutation, using, e.g., Knuth's algorithm.

2

Here is the problem. For a specific ciphertext, sure you could try a bunch of keys and output the couple that result in the type of plaintext you want. But what does this really get you? For a different ciphertext, likely these same keys will not result in the same type of plaintext you desire. Recent work on honey encryption might be what you are really ...

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

If you are concerned about database size, only the master key needs to be stored when you use HKDF. Ditto when sending it to another computer. Otherwise, two independent random keys are clearly secure and simpler to implement, so you should do that.

1

The developers claim that a 6 letter long password hashed with 3.8 seconds of scrypt would cost \$900 to brute-force. Very important: This is the cost of finding the password within a year by building an ASIC in 2002. Not so important: There seems to be only one person behind scrypt: Colin Percival. If we use more cycles, how quickly will the brute ...

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