# Tag Info

6

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

The same key is indeed used in EAX to key both the CTR mode and the underlying OMAC (which is actually used in 3 distinct phases: randomising the CTR nonce, authenticating the Additional Authenticated Data, and authenticating the Ciphertext). This is explicitly acknowledged in the security proof. Where EAX differs from a naive reuse of the key is that it ...

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

4

As noted in archie's answer to your earlier question, the EAX paper first defines a generic encrypt-then-MAC composition method called EAX2, with separate keys for the encryption and MAC components, and proves its security (Appendix C). It then defines EAX as EAX2 instantiated with CTR mode and OMAC, and with the same key used for both components, and then ...

4

Is there a better way to do this? Yes there is, using tools specifically designed for this problem - namely key derivation functions (KDF). Good ones include PBKDF2 and bcrypt. A more modern, better alternative is scrypt, but it's relatively new and could use some more analysis before deemed safe. All above mentioned algorithms take a password and a ...

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

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

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

The shared secret generated by the Diffie–Hellman key exchange is a random element of the subgroup of the multiplicative group modulo $p$ generated by $g$. In particular, for $g$ and $p$ chosen as specified in RFC 2631 section 2.2, i.e. so that $p = jq+1$, where $q$ and $p$ are both prime, $j$ is a small number (often 2, making $p$ as safe prime) and $g$ ...

3

Answering your three questions in order: "If I have a lot (more than $2^{32}$) of files to be encrypted, each file is encrypted using newly generated DPK. Will it somehow cause the MK to be easily found? or easier to find?" It's not going to make it harder. But no, as long as the KDF you're using lives up to its security claims, in practice it should ...

3

No, you don't have to worry about collisions. As long as no pair of users have the same LowEntropy input, they will receive different MasterKeys. If the MasterKey is different, then the AuthKey will be different. Even if you use the same MasterKey to generate multiple AuthKeys, you don't need to worry about collisions: as long as the keynumber values are ...

3

If I understand correctly is to hash your password $pw$ into a point using either $P=Pad(pw)\cdot P_0$ or $P=MD5(pw)\cdot P_0$ and then use $P$ for cryptographic purpose. The exact security of this proposal depends on what you want to do with $P$ exactly. But in some case, this is not secure. Typically, this mechanism is not a good way to hash a password ...

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

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

2

Taken directly from the RFC: The second stage "expands" the pseudorandom key to the desired length; the number and lengths of the output keys depend on the specific cryptographic algorithms for which the keys are needed. The use of the plural here suggests (at least to me) that yes, it's ok to expand the same PRK several times with different ...

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

In addition to the severe problem that minar has shown, using point multiplication has an additional problem; some of the output bits can be computed as a function of other output bits. This is a property that we generally do not expect from a key derivation function. Here's how this works: an ECDSA public key consists of an "X" coordinate and a "Y" ...

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

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

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

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

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

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

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

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

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

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

1

As long as there is a probability that the adversary has the access to a valid signature on the message $m$ using one of the private keys, none of the schemes would be secure, and also any other scheme which is using a linear combination of the keys as the resulting private key. Because, if an adversary has two valid ECDSA signatures on message $m$ which ...

1

You don't need a salt (it defaults to a zero length salt) if you generated the session keys using Diffie-Hellman. You should however use a different info (octet) string for each key in the expand part of the function. The idea is that the salt makes sure that the derived keys are different if the input keying material (IKM) repeats. If no salt is used ...

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