Hot answers tagged

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


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


15

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


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


10

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


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


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

From looking at the source or 7zip that seems to be the case. The format has a place for a salt, as SEJPM's link shows. It is mixed into the homebrewn iterated SHA-256 hash before the key. The 7zip decoder even seems to support salts. However, the encoder never uses a salt. Oddly there is even code for generating a random 4-byte salt, but it is commented ...


6

If you are using the full HKDF each time, you could possibly save time by only using the Extract portion once and Expand once per derived key. That could even halve the total time taken, if you had a worst case situation. Another speedup possibility within HKDF is to use another hash. Either a faster hash or one that matches the required key length better. ...


6

It is very difficult to just read out every storage element on a chip unless the chip was designed to let you do it and especially if the chip was deliberately designed to hinder you doing it. Generic memory chips are obviously easy to read out because they were designed to be read out externally but storage locations inside a complex SoC are another matter. ...


5

Coming up with a specific number is hard. Realistically, all three options take you well out of the realm of ever having more than the absolute worst passwords brute-forced by an attacker. The primary gain of scrypt and argon2 over bcrypt is a hit to parallelism due to the addition of memory requirements. GPUs with thousands cores will need (but don't have) ...


5

An important principle in cryptography is "key separation" which holds that one should "use distinct keys for distinct algorithms and distinct modes of operation". Violating key separation often opens up avenues of attacks that may break confidentiality, integrity, or even recover the key. You can use a KDF to derive cryptographically independent keys from ...


4

There's actually an algorithm designed exactly for this purpose: generating a sequence of keys from one master key. It's called HKDF (HMAC-based Key Derivation Function, paper here). The algorithm essentially boils down to two steps: Extract and Expand. The Extract step accepts any type of "key material" as input, and outputs a pseudorandom key that will ...


4

Instead of generating the random key for the one time pad cipher over and over again, is there a mathematical formula that allows you to switch the key to a new key? No. (Please keep reading…) A single mathematical formula won’t cut it. That’s where cryptographic algorithms come in. There are more than a hand full of cryptographically secure pseudo-...


4

So is 2 the private key here ? No, it's referred to as a "shared secret" (because it is shared between Alice and Bob, and is secret to everyone else). If there were 'private' and 'public' keys (which is not the standard terminology with DH), then Alice's private key would be $a=6$, and the public key would be $g^a = 8$. In this case, the 'private key' is ...


4

I'll answer in order: 1) No, you may not be doing something wrong. This is just the compiler warming up and performing optimizations. The second run you see that AES-128 is already about as fast, which is what you would expect (it should be ever so slightly faster in the end, but that might not even be noticeable). 2) Don't know, you'd have to debug, ...


4

CMAC(masterKey, i) should generally suffice, yes. Note that you would need to specify an encoding for i (e.g. octet string consisting of the big endian encoding of i, left-padded with zero valued octets up to 4 octets). It's probably better to implement one of the schemes defined in NIST SP 800-108: "Recommendation for Key Derivation Using Pseudorandom ...


4

I'll quickly summarize your situation as a TL;DR: You provide a service, using your server, which requires users to get a key, which is identical across devices, without wanting the user to fetch a salt from the server for each log-in and you're only given a low entropy secret to derive a (somewhat) secure key. Safely deriving keys from passwords requires a ...


3

This scheme is vulnerable to a "truncation attack", which allows an attacker to forge new ciphertexts (EN-FILEs). Here's how this works. Assume that the attacker controls a section of the plaintext and can predict (with reasonable probability) the plaintext prior to that section. In another words, a value $A \| B \| C$ is encrypted, where $A$ is ...


3

From the linked page, a minikey is a 30-character string over the base58 alphabet with the first byte fixed to 'S', so effectively 29 characters. This gives a space of $log_2(58^{29}) \approx 169.88$ bits. Assuming that SHA is a random function, the probability of the hash starting with an 0-byte after appending a ? is 1/256, so this check loses 8 bits of ...


3

You don't actually need 384 bits of key material. The IV for GCM does not need to be secret, and may be chosen deterministically, e.g. as an incremental counter. Thus, you only need 256 bits for the AES key, which you already have. That said, if you did actually need more key material, you could use any standard KDF to expand your 256 bits. Since you ...


3

I've been toying around with your function, and I've come to the conclusion it's not memory hard. The amount of required memory can be reduced to at maximum digestsize * 3 * rounds. The first problem is that the entropy does not avalanche throughout the state, but stays localized. For example, after 1 round the state of the 2nd block only depends on the ...


3

AES can have key lengths of 128, 192 and 256 bits. ASCII characters are usually stored in bytes, each byte having 8 bits. But strictly speaking, ASCII only has 7 bits. Thus, concatenating the yields a number consisting of 224 bits or 256 bits. But only 224 bits is not a valid length for an AES key. Since the characters will be entered by a human, that ...


3

With PHP's openssl_encrypt the key length is extended to the length of the key given. So even if you select "AES-128-CBC", by passing a 256-bit key you will get AES-256. (Doing the opposite you get a zero-extended key.) Therefore, all but the first are actually testing AES-256 (and even it may be, if you used a hex encoded key input). As for why the first ...


3

Is there some safe way to sign the private key used for encryption with the signing keys? What you're talking about is also commonly referred to as "keychain" or "keyrings", a concept popularized by programs like GPG, which do exactly this: They generate one master signature key, which you securely distribute and which then "certifies" the other public ...


3

Would these steps result in a suitable pair of keys for AES-encrypt-then-HMAC-authenticate? Yes. That would be fine. It almost is HKDF-Expand, in fact. However, as you note, by deriving the two 256-bit keys from a 160-bit key your effective security will "only" be 160 bits, since an attacker could brute force the intermediate key. That is not at all a ...


3

First of all, the usual way to do this is to generate a new random AES key and then wrap it with the public key. Generally you don't encrypt with the private key at all. Yes, SHA-256 is a one way hash so you can do this. The problem is that you would still need to encrypt with a public key to let the other party know the AES key (unless you use the key to ...


3

The master key has to be stronger in the sense that it's more sensitive than session keys. The information used to derive session keys are not necessarily secret, so if it's easy to recover the master key, an attacker will be able to compute all the derived keys. On the other hand, recover a single session key will not help you to recover the master key ...


3

What you actually want is called a key-based key derivation function (KBKDF). The most prominent KBKDF (and really the standard solution here) is HKDF. This is a function that takes a secret key (e.g. a KEK or a root key or something) and outputs (a set of) derived keys enjoying some nice properties. You can customize the keys to get different keys for ...


3

Like Yehuda Lindell already wrote, MAC does not imply PRF, which is pretty much what you would want from a KDF. Additionally, some of your assumptions are not correct: A key and data as input and an output that has the same length as the input key; This is frequently not the case with MACs. For example, when you use any MAC based on AES-256 (...



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