Hot answers tagged

11

Do all ciphers suffer from the problem of multiple equivalent decryption keys? No. The number of non-equivalent keys is bounded by the number of permutations. Since the number of permutations is very high there is a very big chance that ciphers do not have equivalent keys. This is especially true for ciphers with a high block size (AES with 128 bits). Even ...


10

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


10

There is no such thing as a 16 bit AES key. AES is a block cipher with a block size of 128 bits and a key size of 128, 192 or 256 bits. As a block cipher, AES can only encrypt 16 bytes (128) bits at a time. AES in itsef is not (CPA) secure as repetition of the plaintext would lead to repetitions of the ciphertext. To encrypt larger amounts of data, AES ...


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


8

You're missing a piece in your understanding of modern encryption. AES is a symmetrical block encryption cipher. It describes how to use a key (which can be 128, 192 or 256 bits) long to encrypt and decrypt a single block of fixed size (128 bits) of data. That's it. In order to have a complete encryption/decryption system, you need to couple it with ...


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


7

The comments already have covered the two main points, but let me try to put it in the form of an answer. There are not (that we know) weak keys in AES, in the sense that you cannot formulate a routine $isWeak(key)$. However, there are weak ways to generate an AES key (i.e. bad randomness). An AES key is just a bit string of length $n$. That means that ...


7

How are these keys agreed upon/distributed? Practically speaking is asymmetric crypto a requirement to "bootstrap" and distribute keys? The answers to those questions are beyond the scope of the RFC. So, it depends on the context in which HMAC is being used. The keys can be agreed upon/distributed in any secure manner. The RFC doesn't care. It could be via ...


7

Yes, kind of. The encoding does depend on the individual bits so there could very well be timing differences. Note that the differences would be pretty small; encoding a byte is likely much faster than e.g. modular exponentiation. But as even block ciphers are vulnerable it may very well be possible, especially since table lookup may be implemented. The ...


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

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

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

If $f_k$ is AES the block cipher, then there are $2^{128}$ possible output values for a given plaintext and $2^{|k|}$ possible AES keys, where $|k|$ is either 128, 192 or 256, depending on which AES key size you use. Assuming AES chooses a random permutation, $g_{PT}(k) = f_k(PT)$ behaves like a pseudorandom function*, so you expect something like $2^{127}$ ...


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


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

It depends on the block cipher in question - specifically its key schedule. Knowing any round key of AES-128 would let you calculate the key, because the schedule is reversible. OTOH, e.g. TEA would retain secrecy of most of the key and might remain secure, because its round keys are small enough parts of the key. In the case of DES, it is weak enough to be ...


5

There is some confusion here. The definition of prime numbers states that cannot be factored (see Definition of prime numbers) You seem to be talking about RSA modulus which is the product of two prime numbers (see RSA cryptosystem). As far as keylength is concerned 768 bits is not considered safe today. Note that the keylength choice is a compromise ...


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

The DES operation (both encryption and decryption) ignores the lsbit of each byte of the key. That is, if you flip any of the lsbits within the key, the operation remains the same. That's what is happening in the keys you tried: the ASCII code for space is 0x20, while the ASCII code for ! is 0x21; they differ only in the lsbit. So, if the key has a byte ...


4

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


4

For high security applications using 3DES, NIST recommends using keying option 1 (all keys are different). This is simply because it's the safest. For any application, keying option 1 should be used. If you set K1==K3, then you are reducing your key size to 112 bits, which is less than the smallest key size for AES. Worse still, due to cryptanalysis done on ...


4

yes,it is possible because in meet in the middle attack on 3DES,see below with Complementation Property of DES in red arrow,you can search $2^{55}$ key space instead of $2^{56}$,and for green arrow,you have $DEC_{K2}(ENC_{K1}(M))$ that without key Complementation Property,you need $2^{112}$ operations but with key Complementation Property of left ENC and ...


4

It is important and interesting to notice the different use cases you mention. You don't have millions of software updates you have to sign every day (or second for that matter). For SSL connections, however, you may have millions per second. Given the two use cases, it makes sense that the way you would protect the keys would be different. We don't know (...


4

Apologies if this is too basic but all the explanations about AES focussed on the details of the protocol, not these more basic concepts. In fact you are asking about general secret key management :) 1) Is the point of this (and other encryption techniques) to reuse the same private key for multiple messages? If we're using one-time keys, ...


4

CMAC(masterKey, i) should generally suffice, yes. Note that you would need to specify an encoding for i (e.g. octet string consisting of the big endian encoding of i, left-padded with zero valued octets up to 4 octets). It's probably better to implement one of the schemes defined in NIST SP 800-108: "Recommendation for Key Derivation Using Pseudorandom ...


4

Another solution (cf to @Raoul722 comment) is the following: It is easily feasible with a mix of symmetric and asymmetric encryption. Assume each user $k$ have a key pair: $(K_{pub}^k,K_{priv}^k)$. The admin also have his key pair: $(K_{pub}^{admin},K_{priv}^{admin})$ where $K_{pub}^{admin}$ is known by all. Encryption scheme for a user $k$: generate a ...



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