Hot answers tagged

11

An encryption algorithm does not need a keyspace. By definition, however, it has one. It sound to me like your confusion is mainly terminological. In cryptography, the "keyspace" of an encryption system is defined simply as the set of all possible (distinct) keys that the algorithm can accept. For example, let's say that we're back in the days of the ...


9

XORing a master key (presumably a long term key) with data is a very dangerous idea. If any data key is leaked, then the master key may be easily calculated, thus leaking all keys. ($m$ for the master key, $d_x$ for all data keys) $$c_x = d_x \oplus m$$ then somehow $d_4$ is leaked $$m = d_4 \oplus c_4$$ $$d_x = c_x \oplus m$$ You'd be better off applying a ...


8

Definitions In RSA, an encryption key is a pair of integers $(N,e)$ with $N$ the product of $m\ge2$ distinct odds secret primes $r_i$ (with $0<i\le m$), and $e$ is such that $\gcd(e,\lambda(N))=1$ where $\lambda(N)=\operatorname{lcm}(r_1-1,\dots,r_m-1)$ is the Charmichael function. It follows that $e$ is odd. Typically, other conditions are added, like ...


8

...wouldn't key still get repeated every few hours or so - i.e. you come to the end of the PRG(K)... This is where you are mistaken. Modern cryptographic PRGs simply do no repeat within any conceivable time frame. That is, starting from a seed, a well-constructed PRG (and this is true even when they are not so well constructed, like RC4) will simply ...


8

Most public key encryption schemes, such as PGP, support this. When you are encrypting a message to Bob, in fact you are encrypting the message with a random key using a symmetric cipher, then including the key encrypted to the public key of Bob. $$E_{\text{PK}}(\mathit{Bob}, \mathit{key}) \Vert E_{\text{Symmetric}}(\mathit{key}, \mathit{message})$$ ...


7

If your software needs to decrypt the data and you want to prevent even those with physical access from decrypting without your software, you are basically out of luck. It is impossible to achieve purely in software, since even if a good white-box algorithm existed, an attacker could copy it into their software and be able to decrypt (without directly ...


6

SIV is a mode specially designed for this purpose. SIV-AES would be a good choice, but it has the same issues as AES-wrap; not many implementations. If you use a GCM you should make sure that the IV is unique (if your plaintext is ever not random you would otherwise be in problems). As for the password based key derivation function: yes, PBKDF2 is good, ...


6

In the first part of this answer, I consider the problem of decryption using leaked keys of a protocol not intended for that, which was my original reading of the question. I'll ignore that dominant industry practice is to use random symmetric session keys, leaving little opportunity to "hold a couple of secret keys" without knowing to what session they ...


6

Yes, in any algorithm where keys are just random numbers, reading them from /dev/random is safe. However, /dev/random blocks if the kernel's entropy estimate goes to zero so it is often a good idea to use a user space CSPRNG seeded from /dev/random or /dev/urandom for session keys and other similar random numbers that are used in bulk. The newer getrandom ...


6

What you are looking for is called white-box cryptography. In short white-box crypto aims to make an implementation of a cypher (for example AES) in such a way that it is impossible for an attacker to extract the key, even if the attacker (the user of the computer) has access to the source code and a debugger. Up till now all academic white-box ...


6

Yes a brute force key-guessing attack would be faster, but: It would be ridiculously slow for either. E.g. see this for 256-bit keys. There are faster attacks on both and those attacks break larger RSA sizes than ECC sizes. Related: Why can ECC key sizes be smaller than RSA keys for similar security?


5

I'm using it as a one way encryption on plaintext values such as SSN, names, dates, etc. I suggest rethinking your approach. None of these values have much entropy, so it would be straightforward to bruteforce the original plaintexts (just like cracking a password hashed with a fast hash function). If you're planning to use these values for ...


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


5

Many keys do not consist of a single value. Other key types, such as most symmetric keys, don't have a most significant bit or byte as the key value isn't interpreted as an integer. So this question would be different for each key type and encoding. In general though you would just decrease the "entropy" or key size. This is certainly the case for ECC, and ...


5

Sorry for the late answer, I got busy... So, you know that $\mathsf{Gen}$ is a probabilistic algorithm. What's a probabilistic algorithm? It's an algorithm which, during its execution, can make some random choices, which can be modeled as coin tosses. In programming terms, the algorithm can use a special coin-tossing function, which returns $0$ or $1$ each ...


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

If we take some randomly generated key of AES-128 and we change any random 1 byte of that 16 byte key, will this make huge difference in the AES cipher text generated over same input string? Yes. The outputs with different keys differ greatly. If you pick two random keys the outputs must look completely uncorrelated, or an attacker could gain an ...


5

In two key 3DES two keys are equal so that key size is only 112 bits, compared to the 168 bits of full 3DES. The advantage is a smaller key size without a correspondingly large loss in security: both two and three key 3DES can be attacked in about $2^{112}$ time. With the encrypt-decrypt-encrypt construction it clearly must be the first and last key that ...


5

The key size is simply the amount of bits in the key. With AES, like most modern ciphers, the key size directly relates to the strength of the key / algorithm. The higher the stronger. AES is a bit different with respect to the key size in the sense that both the key schedule and the number of rounds are different for each key size. Because of this there ...


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

Each 56-bit key has a unique 8-bit parity value. For this reason there are only $2^{56}$ keys.


3

In 2013, I visited the National Cryptologic Museum and researched/photographed the donated materials on the Chaocipher from the Byrne family. As it pertains to your question regarding the security of the cipher, it is true that while the original algorithm has been now been known for several years, to date no known cipher-text only decryption has yet been ...


3

No it does not affect the parity bits. The plaintext or ciphertext doesn't have any parity bits specified. The application key is just a input to the cipher, which is a Pseudo Random Permutation. Permutation means a 1:1 mapping from plaintext - including parity bits - to the ciphertext. If you perform the permutation in the opposite direction the plaintext ...


3

The "obvious" (it really isn't that obvious) thing you are missing is: The same reasoning could be applied to literally any other private key! There is nothing special about $a=\lvert(\mathbb Z/p\mathbb Z)^\times\rvert=p-1$ (which would, by the way, more commonly be represented as $0$ modulo itself), except that checking for it is particularly easy. For ...


3

The very fastest elliptic curve algorithms can generate a key-pair in about 40k cycles on a modern CPU. A high end laptop has four cores running at about 3 GHz, so it can generate about 300k key-pairs per second, or a billion per hour. (The cost of SHA-256 is negligible in comparison.) However, secp256k1 is nowhere near the fastest curve. It takes 10 times ...


3

I would just concatenate. Two 256-bit keys lead to a 512-bit key which is short enough for HMAC with common hash functions to use as is. XOR would allow the second party to easily choose a related key (and has worse behavior when neither key is perfectly random). Hashing and double HMAC use more resources without a clear benefit, unless you care about the ...


3

If a cryptosystem is expecting a 16-byte key, making the first byte nonzero simply reduces the number of possible keys. It is better to allow all bytes to be all values.


3

Simply put: No. First recall that this is a mis-use of the term "One Time Pad" So lets call it a Vigenère cipher instead. You can determine this is insecure with a simple algebraic combination: $ \text{attack} = cipher_1 + cipher_2 + cipher_3 + cipher_4 \\ \text{Simplify: } \\ \text{attack} = character_1 + key_1 + IV_1 + character_2 + key_2 + IV_1 + ...


3

A keyspace is the set of all possible keys; it's a set. The cardinality of the keyspace is an integer, and is the number of elements in the keyspace. There is no possibility of confusion, because one is a set and the other is an integer.


3

In the context of encryption schemes, the key is whatever piece of information the legitimate recipient of an encrypted message possesses, which allows him to decrypt the ciphertext efficiently. Hence, the key must be kept hidden from an attacker, since otherwise the attacker could decrypt efficiently just as the legitimate recipent does.



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