# Tag Info

70

I'll try to take a stab at this. From Apple's iOS Security Guide, we learn that The metadata of all files in the file system is encrypted with a random key, which is created when iOS is first installed or when the device is wiped by a user. The file system key is stored in Effaceable Storage. Since it’s stored on the device, this key is not used to ...

23

The best you can hope for is the following: You derive the password into a "big enough" (e.g. 128 bits) secret key $K$ with a Key Derivation Function like PBKDF2. There are some details to be aware of (see below). You use the secret key $K$ as seed for a Pseudorandom Number Generator. The PRNG is deterministic (same seed implies same output sequence) and ...

18

The XOR is indeed meant as a protection against hypothetical short cycles. For a given password $P$, the sequence of $U_i$ should make a "rho" structure: at some point in the sequence, a cycle is entered. For a $n$-bit hash function and random password, on average, there will be a single "big" cycle of size about $2^{n/2}$ and for almost all possible salt ...

16

Even if the 32 characters are completely random, they won't contain non-printable characters. Actually, there are only about 107 printable characters in ASCII (out of 256 values for a full byte) and that even includes the space character. So if all the printable characters are used, it would result to a security level of about $log_2(107^{32}) = 215$ bits, ...

14

What you suggest is valid. Here is a way to show it: In a fully implemented signature system (things are similar for asymmetric encryption), there are three modules: a key pair generator, which produces a pseudo-random key pair; a signature generator, which uses the private key to produce a signature over some piece of data; a signature verifier, which ...

14

Both PBKDF2 and scrypt are key derivation functions (KDFs) that implement key stretching by being deliberately slow to compute and, in particular, by having an adjustable parameter to control the slowness. The difference is that scrypt is also designed to require a large (and adjustable) amount of memory to compute efficiently. The purpose of this is to ...

14

The encryption key isn't derived only from the passcode; it's also derived from a number of cryptographic keys etched directly into the CPU's silicon. These keys are impossible to read out in software—there are only instructions to encrypt and decrypt with them—and have been made purposefully difficult to extract by inspecting the hardware. Without the ...

12

KDF must produce results that have certain randomness properties, and be very difficult to reverse. Password hashes only need to satisfy the property "difficult to reverse", without randomness requirements. This is why all KDFs work as password hashes but not the other way around.

12

No. A MAC guarantees unforgeability but not pseudorandomness. It is true that all MACs that I can think of right now are essential pseudorandom functions, but this does not mean that the MAC definition implies this. Indeed, it clearly does not. So, conceptually, you need a pseudorandom function. You can assume that HMAC is a pseudorandom function. It is ...

10

I'd use HKDF's "expand" step to generate multiple keys from one masterkey. Use PBKDF2 to derive that masterkey from the password and salt. i.e. replace the "extract" step of HKDF with PBKDF2. //Extract MasterKey = PBKDF2(salt, password, iterations) //Expand AES-Key = HMAC(MasterKey, "AES-Key" | 0x01) MAC-Key = HMAC(MasterKey, "MAC-Key" | 0x01) (where | ...

9

Short answer: just truncate, it's fine. Long answer: you want a Key Derivation Function. A KDF turns an arbitrary-sized input (the shared secret obtained from SRP) into a configurable sequence of bytes, which you can split into as many sub-sequences as you need for symmetric cryptography. For instance, SSL/TLS defines a KDF (it calls it "PRF"; see section 5)...

9

Yes, this is a fine approach. This sort of technique is known as "key separation". Since your master key is a cryptographically secure key, you do not need to use a large iteration count. Also, you could use any PRF, in place of PBKDF2. (The iteration count is normally used if you are applying PBKDF2 to a passphrase, instead of a cryptographically secure ...

9

For the purpose of key diversification (that is, assigning a unique key per device), a true master_key is customary; that is, one with plenty of entropy (like, 128 bits or more random bits). Edit: that's now stated in the question. With that caveat, yes, PBKDF2(password=master_key, salt=serial_number, rounds=1000, dkLen=16)is appropriate to generate one 128-...

8

Let's start with a general secure KDF construction, as follows. Let $F(k,x) \rightarrow \{0,1\}^n$ be a secure PRF. Then choose $L$ such that $L \times n$ provides as many output bits as you need for all of your generated keys. Let $S$ be your original secret key/entropy. Generate the following string: $KDF(S,N,L) := F(S, C || 0) || F(S, N || 1) || ... || F(... 8 @D.W. is probably closest to the real reason (this was fifteen years ago, so things get a bit hazy), there was some concern about short cycles, and it was effectively free - you're already iterating the hashing deliberately to slow things down so speed isn't an issue - so why not do it? You've also got to remember the historic context, when replacements for ... 8 You can use TLS 1.0 as guidance: it is the direct successor of SSL 3.0, so many things are quite similar, and in some respects TLS 1.0 is a bit clearer. In section 6.3 you will find the key generation process, with the exact sentence: To generate the key material, compute [...] until enough output has been generated. Then the key_block is ... 8 If you want key diversification with a key as input, you are better off using a key based key derivation function (KBKDF) over a password based key derivation function (PBKDF). Difference is that KBKDF requires a key with high entropy. This also means that it does not require a salt nor an iteration count. It does however require context specific data for ... 8 It looks like, given your adversary model, things should be secure. HMAC as a randomness extractor has been shown to be good, especially when we can assume the hash function is collision resistant. That paper also has some results which tell how you could guard against the collision resistance being broken (basically use a hash function with larger output ... 8 The strength of a symmetric key is determined by the amount of entropy. In that sense your scheme would not increase or decrease the security by much. However, you would be specifying a higher key size than actually used. For instance your AES-256 bit key would have the same entropy as an AES-128 bit one. You'd use a slightly different key schedule and ... 8 You need to split this up into two separate problems: you may have a low entropy password (as you indicate you want to have "tunable difficulty"); you need the keys of a specific user not to reveal any information about the password or the other keys. Lets solve this in two steps: First you need a salt and a work factor or iteration count. You can do ... 7 A common approach is to encrypt the private key with a symmetric key derived from a pass phrase. This will be as secure as the chosen pass phrase. I'd suggest sticking with this approach; its conventionality makes it "simpler" than a solution that hasn't been studied well. 7 As mikeazo notes, PBKDF2 supports the generation of arbitrary amounts of key data. It accomplishes this simply by appending a running counter to the salt and rerunning the key derivation process to generate new output blocks, so there's no obvious reason why you couldn't apply the same construction to bcrypt. The scrypt KDF also supports arbitrary-length ... 7 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\$ ...

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

7

Read Marsh Ray's analysis. PRF in TLS is designed to be the most conservative aspect of TLS (the last part of TLS to break). Mr. Marsh calls it "the slowest, most conservatively designed stream cipher in common use". TLS PRF seems to be NIST sp800_108 in "Double Pipeline Mode". What Tim McLean contemplates above as a potential alternative is sp800_108 in "...

6

To be honest, there's no good reason why the XOR is needed. My suspicion is that, most likely, the designers included it because they thought, "hey, why not? it can't hurt". But if the designers had left out the XOR, everything would have been just fine. In particular, if PRF() is a secure pseudorandom function, and if we stick with typical parameters, ...

6

In my practice (Smart Cards, often using DES and increasingly AES) Key Expansion is often used to designate production of subkeys in a block cipher. This process is often a mere bit extraction, as part of the algorithm's Key Schedule. Key Diversification is, almost exclusively, the process of producing a device key from its serial number (or other ...

6

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

6

First, realize that PBKDF2 is PKCS #5 is RFC 2898, i.e. http://www.ietf.org/rfc/rfc2898.txt It's essentially an algorithm to securely hash a password as many times as you want, with whatever hash you want. OWASP recommends hashing the password at least 64,000 times in 2012, and doubling that every two years, per https://www.owasp.org/index.php/...

6

It's called a key derivation function because that's what you'd typically use its output for — as a key for some other cryptographic algorithm. (Of course, you can also use the output of Bcrypt for other purposes, e.g. storing it in a database as a password hash, but that's really a secondary use case.) In general, key derivation functions (KDFs) ...

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