# Tag Info

15

Examining his claims about "Thundercloud": You can use it with "any existing software, operating system, or device" (a massive amount of effort---by whom?) Has its "own cryptographic language that is completely independent of any existing security technology" (this is a negative thing: abandoning the entire knowledge base of cryptography is incredibly ...

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

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

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

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

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

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

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

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

Key length is the length of the key. It's a term whose meaning has evolved over time; these days, it typically means length in bits. With digital symmetric ciphers, it's fairly simple, because those tend to have a key that's just a string of some number of bits, and any string of that length is a valid key. With RSA, it's more complicated - the key has a ...

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

Trevor Perrin wrote a library doing exactly that. Explanation can be found on in the curves mailing list archives. To convert a Curve25519 public key $x_C$ into an Ed25519 public key $y_E$, with a Ed25519 sign bit of $0$: $$y_E = \frac{x_C - 1}{x_C + 1} \mod 2^{255}-19$$ The Ed25519 private key may need to be adjusted to match the sign bit of $0$: if ...

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

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

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

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

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

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

Yes. $\:$ "simply XORing" is obviously malleable, which may allow related-key attacks. "When storing a short key, e.g. a 256-bit ECC private key," the "good reason to use AES" is that "the XOR with a single PBKDF2 (or other KDF) output block" is not necessarily sufficient, since an adversary might also have changed the stored public key.

3

First of all, I suggest you to try use as IV first 16 bytes of encrypted file. Because in general IV is the first block of ciphertext. But if that doesn't work, then – of course – you can decrypt all message except first block. Just use first block as IV, and start to decrypt from second block. That will work because CBC does not provide integrity, and ...

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

Your description of how RFC 5959 works isn't quite right. It is not quite correct to state that RFC 5959 encrypts using AES in ECB mode. A correct statement is: if the plaintext is exactly 128 bits, then use ECB mode, otherwise use a non-trivial mode of operation found in RFC 3394. In the former case, ECB mode is fine, since it's just a single block of ...

2

HMAC: The hmac version is considered slightly more secure than sha-256, assuming it's also based on SHA-256, because the HMAC formulation folds in the key material with 2 rounds of hashing, making it harder to use a chosen plaintext attack on the digest. SHA-256: SHA-256 should be relatively secure against chosen plaintext attacks, but it's better to be ...

2

I'll start with the last point and use the notation for ECDSA from the wikipedia article. Does it make any more difference if there is data that is known to have been signed by the private key and the signature(s) are known and the raw data is known? When using a digital signature scheme, the parameters (used group, e.g., elliptic curve group) as well ...

2

From my recent experience, it's not always compatible. Using the latest version of GnuPG and Symantec PGP, I was able to confirm at least the fact that a 16384-bit RSA key pair (with 4096-bit subkeys) generated in GnuPG will not be usable in Symantec PGP. All of the cipher, hash algorithm, and compression preferences will be displayed as none, the expiry ...

2

Here is the problem. For a specific ciphertext, sure you could try a bunch of keys and output the couple that result in the type of plaintext you want. But what does this really get you? For a different ciphertext, likely these same keys will not result in the same type of plaintext you desire. Recent work on honey encryption might be what you are really ...

2

AES-256 with $b$ bits of its key known is still secure against key recovery attacks with security level $(256-b)$ bits. Otherwise a shortcut key recovery attack on the regular AES-256 would exist, and the only known attack of this kind -- biclique attack -- does not scale to such subsets of the key space.

2

I know how Diffie-Hellman Key Exchange works. Is this the main way of encrypting with PGP, ssh, ssl (https), DKIM, ...? As the name says Diffie-Hellman key exchange is a key exchange protocol, i.e., a protocol where two parties agree on a common secret without having exchanged any secret prior to that, in an interactive way, i.e., both parties are ...

2

AES is based on shuffling and XOR operations. Therefore, unlike in RSA, primality plays no role in AES. Any key generated from a cryptographic-quality random number generator should do. Issues to watch out for are weak keys (to my knowledge, there are none in AES) and related-key attacks (don't encrypt the same message with keys that resemble each other and ...

2

Picking up what has been said in the comments: to simplify: symmetric ciphers are like mathematical operations with 2 operands and 1 result. There is The plaintext message $m$ and $k$ as the key and they result in the ciphertext $c$. In your example, the algorithm can be cut down to a addition and modulo: $c = (m + k) \mod k_{max}$ And of course there is ...

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