Hot answers tagged

69

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


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


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


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


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

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

There are two things here: Encryption uses mode of operation, and not "AES alone". Some of them are randomized by an initialization vector - that means the encryption of the same text under the same algorithm is still randomized and not deterministic. The encryption methods take care of that. You only need the correct key to decrypt. Passwords are not ...


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


5

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


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

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


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 handfull of cryptographically secure ...


4

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


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


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

I don't think it is a good idea, for two main reasons. Firstly, you are basing your security on the obscurity of a parameter that was not designed initially for being secret, which is a risky practice. It is similar to hiding the salt. Secondly, following your example, you may in principle think that a random number of iterations between 10 and 100,000 is ...


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

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

TL;DR: You put less of a burden an any attacker trying to brute-force this. And please note: Implementing PBKDF2 shouldn't be much harder than implementing your approach. Now let's head over to the explanation why "your" scheme is really bad for password-hashing. The scheme you propose is that each try cost you exactly two hash-function evaluations. One ...


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

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


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

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


2

$s$ is a shared secret key. It's known to both Alice and Bob. You could call is a private key, but the usual terminology is “secret key” here, for no deep reason. Alice has a private/public key pair: $a$ is her private key, $A$ is her public key. Ditto with $b$ and $B$ for Bob. These values are not useful in isolation though; in normal use, the only point ...


2

That's because AES is not a password-based encryption algorithm. It's a block cipher. It may seem like a detail, but such details matter. In cryptography, and in security in general, details often matter. AES is a pair of functions, each of which takes a key and a 128-bit message and produces a 128-bit message. The two functions are called encryption and ...


2

Is this approach (deriving a password from a signature) cryptographically sound? Not in general. There are signature algorithms that are completely deterministic and signature algorithms that aren't. With the latter kind you would be unable to reproduce the password later. With a deterministic algorithm, yes, the basic idea of using the signature as a ...


2

How they work Public and private keys work as follows. Every party who wants to communicate with others generates a private key which they keep secret. From that private key, they derive a public key, which they publish for anyone to see. For example, if we have three agents, Alice, Bob, and Charlie, they will all have a secret key S_A, S_B, and S_C and a ...



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