# Tag Info

## Hot answers tagged keys

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

5

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

3

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

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

2

If you just want a good secret, read the number of bytes you need from /dev/random on Linux. On windows, someone else has to complete the answer.

1

If /dev/random is working as it should, yes it is safe to generate a key by reading from it; same for /dev/urandom, which is supposed to be equally safe, and non-blocking, thus always preferable to /dev/random. However, in practice, it is very easy to make a port of /dev/random (or its underlying entropy sources) that seems to work, but does not, and will ...

1

While there is nothing special about most key values, the public key 1 is actually not permitted. It would result in the same shared secret 1 with every other key, because $1^x = 1$ for any private key $x$. When using public key validation, the key is checked to be in the range $[2, p-1]$. This is ensured if the private key is chosen from $[2, q-2]$. For ...

1

This kind of key management problem is a big reason why encryption is not more widely used for everyday data. I see a single easy way to do this, I think it is similar to the way disk encryption systems work, and it may not work for your uses. For each file, a random key $kf$ is generated. 2 copies of the key are encrypted, one with a key derived from the ...

1

Microsoft Security Account Manager (SAM) Remote Protocol has a way to map 7 bytes to a DES key, similar (possibly identical) to the question's "concatenating the 7 bit chunks together, left to right (big-endian sense)". One way to see it is that the key bits are laid out on a line, by increasing indexes of bytes and within that in big-endian order (that is, ...

1

The one time I've seen a system compress a DES key into 7 bytes, it did it by logically placing the 8 bytes of the standard DES key into an 8x8 table, and then flipping the table along the diagonal axis, so that bit x of byte y of the standard DES key was mapped to bit 7-y of byte 7-x of the compressed key. For example, the first byte of the compressed key ...

1

I'll be answering the question as in its body, which does not match the title (double encryption implicitly refers to using the same block cipher for each encryption, when the question is explicitly about two block ciphers). With only the hypothesis that $A$ and $B$ are secure block ciphers sharing block size and key size, we can't conclude that the ...

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