Tag Info

Hot answers tagged

16

Curve25519 was designed to take advantage of the Montgomery ladder, which combined with Montgomery curves forgoes the $Y$ coordinates, is side-channel resistant, and enables public keys to be any 255-bit string. The ladder looks something like this (pseudocode): Q[0] = P; Q[1] = 2*P; for(int i = log2(exponent) - 2; i >= 0; --i) { Q[ bit(exponent, i)] ...


10

This depends on the public-key system (algorithm). For RSA, technically the private and public key (i.e. the exponents, the keys share the same modulus) are symmetric, you can swap them, and it still works. But you usually don't want to do this: The public exponent is usually a small number (like $3$ or $2^{16} + 1$) in order to speed up ...


8

The problem is a very old one going back at least as far as the late 1940's early 1950's and has been shown to exist with Quantum Key Exchange as well. You need to think of it in terms of entropy down to heat pollution where a coherent signal energy steps down due to inefficiency via various transducers to what is basically thermal noise where the noise ...


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


6

While it may be confusing, that Wikipedia article is actually correct! Let me try to explain it a bit better… Definition of key whitening Key whitening is an extremely simple technique to make block ciphers like DES much more resistant against brute-force attacks. Like you’ve already discovered yourself, this is the basic scheme: Or, defining it a bit ...


6

Did you take a look at DjB's paper? One of his design criterias in order to improve performance is "Use a fixed position for the leading 1 in the secret key". The set of secret keys is defined to be $\{\underline{n} : n \in 2^{254} + 8\{0, 1, 2, 3,\ldots, 2^{251}-1\}\}$.


6

Efficiently - no. However, the best attack on DES - linear cryptanalysis - works with known plaintexts, and theoretically may work slightly faster than the brute force even for small amounts of data. Computing linear relations between plaintext $P$ and ciphertext $C$, an attacker is able to enumerate all keys according to their likelihood. The PhD thesis by ...


6

Start by reading the paper. They have an entire section on defences: it is Section 11, Mitigation, pp.46-48. As far as software countermeasures for RSA specifically, they mention blinding as a good defence. Blinding is a standard defence against many kinds of side-channel attacks, and it is apparently effective against acoustic cryptanalysis as well. ...


6

As stated in the comments, dev/random already produces cryptographically secure random bytes which are perfectly adequate for use in encryption keys. Running these bytes through another CSPRNG is completely redundant. As far as I've understood, one of the options to create cryptographically secure keys would be to gather entropy from /dev/urandom/ and ...


6

The only reason you are seeing this is because you are dealing with such small primes. With primes like we would use in practice (1024 bits), the probability of this happening is very, very small. And, it can only happen when $e>\sqrt{\lambda(n)}$. Since we typically use $e=65537$ in practice, it is guaranteed to not happen. Anyways, there is no mistake ...


5

With proper hashing the entopy of $Z$ is roughly the sum of both individual entropies, capped to the strength of the hash-function. For SHA-256 the limit is 256 bits, for SHA-512 it's 512 bits. Since entropy above 256 bits is meaningless, this isn't a practical limitation. For XOR computing the entropy of $Z$ is tricky and depends on how your keys are ...


5

"If PGP and GPG both follow the OpenPGP standard, are they 100% compatible in all use cases?" No, they are not 100% compatible in all use cases, because — depending on the PGP version — there are known interoperability problems. The GNUPG FAQ answers this question quite well: Is GnuPG compatible with PGP? In general, yes. GnuPG and newer PGP ...


5

Quite apart from the correction that Reid made (it takes $2^{127}$ attempts to achieve a probability of 50% of finding the right key; with $2^{64}$ attempts, the probability of success is $2^{-64}$), with AES, there is no known way to take advantage of known (or even chosen) plaintext to speed up any brute force search; even with $2^{64}$ chosen ...


5

Currently, I’m hashing (SHA2) a few extracted bytes I collect from a CSRNG to create keys for AES encryption/decryption. Is that wrong? Depends on what you mean by "a few"; if you mean 16 or more, then yes, that is likely to be secure. However, if you mean, say, 4, then that is Very Bad. The reason is that the hash function doesn't do magic; if you ...


5

No, it does not have to be a prime. All you need is an appropriately long and random key: AES-128 = expects key-length of 16 raw/binary bytes (= 128 / 8 bits per byte) AES-192 = expects key-length of 24 raw/binary bytes (= 192 / 8 bits per byte) AES-256 = expects key-length of 32 raw/binary bytes (= 256 / 8 bits per byte) As a practical example, you ...


4

To answer this question, we must have a look at how TLS/SSL works. I guess you know that the aim of TLS/SSL is to authenticate communicating parties before setting up an encrypted connection through which application data will flow. And as you may already know, an SSL handshake/session will use asymmetric crypto for authentication and session setup and ...


4

If you use public key crypto in the correct way, then every user has it's own private key and corresponding public key (included in the certificate) and the keys of users are not related. Consequently, compromising the private key of one user does not affect any of the other users. So in the case of compromise of the private key of one user the remaining ...


4

Short Answer: NO, it is not safe, do NOT do this. Longer Answer: You are true that you can use your RSA keypair for both operations. This approach is used in many applications and scenarios. There are Web Services or Single Sign-On implementations, which enforce you to use the same key pair for both operations. X.509 certificates do not allow you (by ...


4

A key derivation function lets you derive keys from others. In this case I would use HKDF, which means using HMAC in a predefined way. Your key material is the keys $X$ and $Y$, so you can concatenate those to get the PRK for HKDF-Expand. An output key would then be $\operatorname{HMAC}(X||Y, \text{info} || \text{0x01})$, if the size of the HMAC is long ...


4

According to the paper “Stronger Key Derivation Via Sequential Memory-Hard Functions”… If $$2^k = x$$ the entropy of the derived key (DK) key will be $$2^{k}+y$$


4

The idea you describe is vulnerable to a meet-in-the-middle attack that work in approximately $2^{128}$ time and $2^{128}$ memory. The attack assumes knowledge of plaintext/ciphertext pair(s). Given a pair, you encrypt the plaintext with every possible key 1 and store those values. You then decrypt the ciphertext with every possible key 2 and look for a ...


4

Yes, absolutely. Here is the standard construction to address this problem. Let $pk_1,\dots,pk_n$ be the public keys of the $n$ recipients. We pick a random symmetric key $k$, encrypt the message $m$ (using authenticated encryption) under key $k$ to get $c=AE_k(m)$, and then encrypt $k$ under each of the public keys. Finally, we form the whole ciphertext ...


4

The short answer is NO. Generally, it is not true that for RSA with no padding, the length of data must be equal to the key length. When and if that applies, that's a restriction of a particular cryptographic library, and either that's not the only restriction about the data, or the library does not allow reliable decryption of what's encrypted. RSA ...


4

The authors of the paper might be able to tell you; I suspect no one else will. You are having problems understanding the paper; a large part of the reason is that the paper isn't very well written; it introduces terminology (such as "ph") without ever defining it, and includes things that don't make any sense, such as the first line of their "Encryption ...


4

In this scenario, it is better to use AES-128 than AES-256 if you are to 0-pad a 128-bit key to 256 bits. If you 0-pad, the round key for round 1 is all 0s, and round 3 is effectively worthless as well. So now you are down to 12 effective rounds vs 10 for AES-128. Then you need to look at the effectiveness of the remaining keys. Here are some example key ...


4

You need to split up your key into eight 7 bit pieces, and put these 7 bits into a byte each. The parity is in the least significant bit on most platforms, so the 7 bits need to go into the most significant bits. Of course, as the key is probably in bytes, you need to shift and combine the values in the bytes to retrieve the 7 bits. It's possible the ...


4

Am I going to regret posting this? There seems to be enough non-classified information available about GPS to answer this question. I see 3 reasons why P(Y) encryption is different and less likely to be hacked than game console encryption: Hardware containing the GPS decryption key is more difficult to obtain than hardware containing the game console ...


3

One way key whitening improves security is by increasing resistance to bruteforce attacks (and doing this essentially for free). Consider, for example, DES. Key is 56 bits, so given a single pair $(M, E=DES(K,M))$ attacker will find $K$ in $2^{55}$ operations on average. By employing key whitening it is possible to increase required effort substantially: we ...


3

No. This is known as a known-plaintext attack, and AFAIK no such attack is faster than bruteforce for DES. However, DES only uses a keyspace of $2^{56}$, so you could theoretically still bruteforce it.


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



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