77
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 ...
45
You asked for the practical impact, so the answer is that for \$120 I could probably have your entire password database done by tomorrow.
Here is your program, or something similar to it:
using System;
using System.Text;
using System.Security.Cryptography;
class Program {
static void Main(string[] args) {
byte[] pwd = new byte[128];
...
31
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 of cores will need (but don't ...
28
The HKDF paper provides as good a summary as any:
A Key derivation function (KDF) is a basic and essential component of cryptographic systems: Its goal is to take a source of initial keying material, usually containing some good amount of randomness, but not distributed uniformly or for which an attacker has some partial knowledge, and derive from it one ...
27
The algorithms themselves just output binary (i.e. bytes) if you read their specifications. It's the implementation in API's and applications that output the hexadecimals and/or base64.
Sometimes there are also ad hoc standards / common practice that specifies a certain output format. This is for instance the case for the output of the bcrypt password ...
26
Using Base64/HEX has nothing to do with security of a hash algorithm.
Base64 and HEX are ways to represent binary data, which is the actual output of a hash algorithm.
Base64 is shorter simple because it uses a larger charset than HEX. (64 characters vs 16 characters)
Besides, algorithms like SHA-256 and SHA-512 are only "unsafe" when used for password ...
26
From what you have described, it sounds like your system works as follows:
Consult the system clock to find a 32-bit seed $s$.
Use System.Random to generate a passphrase $p = G(s)$. (Here $G$ is shorthand for whatever computation happens inside System.Random.)
Hash the passphrase with PBKDF(2?) into output $x = H(p, \sigma)$, where $\sigma$ is a salt known ...
21
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 ...
21
Cryptographic hashes are designed to be fast and collision resistant. It turns out that when hashing passwords, it is more secure to have a slow hash function. One way to make a fast hash function slow is to iterate it. Like is done here.
Think about it this way. If an attacker is able to compute a million hash calculations in a second, if you only ran your ...
19
The "s2k" options correspond to the String-to-Key specifiers. An s2k transform turns a human-compatible symmetric secret (a password or passphrase) into a symmetric key suitable for a symmetric encryption or MAC algorithm.
Turning passwords into keys is tricky business because passwords that human can remember and accept to type tend to be weak ...
19
No, you do not need to do escaping or sanitization on data that you pass in as the user input to these functions. They accept arbitrary byte sequences, so any arbitrary byte sequence you pass is acceptable, and there should be no security risks as a consequence of it. In general, cryptographic algorithms operate on arbitrary byte sequences (possibly of ...
18
The official documentation for System.Random explicitly says it should not be used for generating passwords. It’s predictable, and seeded only from the system clock. This means System.Random has at most 20 bits of entropy to anyone who has a clock accurate to within a second.
Indeed, try creating two new instances in quick succession on different threads; ...
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, ...
16
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 ...
16
KDF's or Key Derivation Functions are functions or schemes to derive key or output keying material (OKM) from other secret information, the input keying material (IKM). That information may be another key or, for instance a password. It is important that the secret contains enough randomness to generate keys, without an attacker to be able to perform attacks ...
15
In principle raw SHA2 is suitable for deriving an AES key from a DH shared secret.
But the "proper" solution is to use a KDF. My preferred choice is HKDF, which can use SHA256 as the underlying hash function. It allows you to derive several named key and keys longer than 256 bits from a single secret.
15
Yes.
Actually any cryptographic hash function should be fine and allow you to reduce the problem of breaking your AES encryption to either:
breaking your DH protocol, this follows from the fact that secure hash functions are meant to be "one-way" function.
brute-forcing the AES key, since the output of a good hash function is distributed uniformly ...
15
Multiple Key Generation from a Master key
HMAC-based Key Derivation Function (HKDF) rfc5869 is what you are looking for. HMAC security proof uses the fact that the compression function of the underlying hash is itself a PRF.
HKDF follows the "extract-then-expand" paradigm, where the KDF
logically consists of two modules. The first stage takes the ...
14
Yes, it is. PBKDF2 derives a DK, a "derived key", which is indistinguishable from random. This is mainly because function within PBKDF2 is HMAC, and HMAC is a PRF. Let's see the definition from Wikipedia:
In cryptography, a pseudorandom function family, abbreviated PRF, is a collection of efficiently-computable functions which emulate a random oracle in ...
14
SHA-512 has both a larger internal state and a higher number of rounds than SHA-256 - which means that it provides a higher bit strength. Somewhat surprisingly it may also outperform SHA-256, as it uses 64 bit word size, which works best on 64 bit processors. You can see a good comparison table on Wikipedia
If less bits are required from SHA-512 then they ...
13
I did also tried to find a good value for the -a flag, in a MacBook Pro Mid14 (i7), trying to login in to a Debian 8.5, I had this results:
-a 1000 Took about ~20s.
-a 100 Varies between ~3.5s to ~6s.
-a 64 (4x default value) ~3 to ~9s.
-a 16 (default) ~2s ~2.5s.
In the end I just stick with the default since I'm not a paranoiac and I don't like to wait, ...
13
can any block cipher in CTR mode be used as a CSPRNG?
Formally speaking the CTR mode transforms a PRF (or a PRP) into a PRG and as the PRP notion is the standard notion to model block ciphers, pretty much all secure block ciphers should yield a secure PRG when used in CTR mode.
Less formally speaking CTR mode transforms a secure block cipher into a secure ...
13
Assume you have an IND-CCA secure cryptosystem $E$ that runs a password through a slow KDF and implicitly handles salts and random IVs, a human-chosen password $p$, and messages $m_1$ through $m_n$ to encrypt. Is $E_p(m_1+m_2+\cdots+m_n)$ or $E_p(m_1)+E_p(m_2)+\cdots+E_p(m_n)$ better for this? Each invocation of $E$ is slow due to it running a KDF on $p$, ...
12
Slower is better, as slow as you can tolerate. Timing for different -a values, each measured 20 times:
-a 16 takes on average 0.247 (seconds)
-a 32 takes on average 0.586
-a 64 takes on average 1.206
-a 100 takes on average 1.962
-a 150 takes on average 2.664
The time is linear, so you can expect a doubling of the -a value to take twice as long. The ...
12
The entire point of a key-derivation function like Argon2 is to increase the time (difficulty) it takes to create a key, and as a side effect, increase the resources required to attack the key.
The problem with other key functions like PBKDF2 is that you can only set the total iterations required, while this is fine for many applications, it isn't ideal for ...
12
Am I correct in assuming that this does not add any extra security?
No. This does add security and is a standard practice when dealing with passwords. What they do there is called a password hashing scheme (PHS), sometimes also referred to as password-based key derivation function (PBKDF). Other common instances of this are Argon2, bcrypt, scrypt or PBKDF2 ...
11
Yes, it is possible to deterministically generate public/private RSA key pairs from passphrases. For even passable security, the passphrase must be processed by a key-stretching function, such as Scrypt (or the better known but less not recommendable PBKDF2), and salt (at least, user id) must enter the key-stretching function; the output can then be used as ...
11
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 keys. ...
11
A key derivation function (KDF) takes in some secret keying material, which may or may not be uniformly distributed, and where the adversary may also have some auxiliary information about the keying material or its distribution, and outputs a uniformly distributed bit string. See definitions 5, 6, and 7, here.
Intuitively, a KDF's job is to take in some ...
Only top voted, non community-wiki answers of a minimum length are eligible