Tag Info

Hot answers tagged symmetric

16

TL;DR No, the approach is not secure. Use a standard like CMAC instead. Or even better, check your AES accelerator module to see if it supports any AEAD modes of encryption like GCM, CCM, EAX. Long Version In order for a message authentication code (MAC) to be secure, an adversary with oracle access to the MAC (basically this means the adversary can send ...

16

The number of possible permutations of a block cipher are $2^n!$ where $n$ is the block size. A permutation maps all $2^n$ possible input blocks to $2^n$ possible output blocks. A key, with key space $2^k$ selects one of them. Although that's a huge number of keys, it is dwarfed by the amount of possible permutations. Now it's not by definition impossible ...

10

Apparently there's at least one real-life example of a block cipher with equivalent keys: TEA has a few weaknesses. Most notably, it suffers from equivalent keys—each key is equivalent to three others, which means that the effective key size is only 126 bits. As a result, TEA is especially bad as a cryptographic hash function. This weakness led to ...

8

As typically implemented, PBE takes a low-entropy, user-supplied password, adds some entropy to it, and thus strengthens it before turning it into a key. This key can then be used for symmetric encryption. The problem is that the user's password often has so little entropy to start with. If an attacker learns the salt, digest method and quantity of ...

8

You are correct: The 'workhorses' or primitives of cryptography, hash functions and block ciphers, can be used in such a way that they accomplish each others tasks: A hash function can be used to generate a key stream just as a stream cipher or block cipher in CTR mode (see e.g. Salsa20). And a block cipher can be transformed into a hash function (e.g. a ...

7

I've checked out the source code (well, more or less, it's not that well designed, the main crypto class is 1600 lines) and as Richie guessed, the algorithm is stored together with the ciphertext. Pretty gruesome stuff, but it does do EAX mode for text strings to my surprise. It probably only uses it for text strings originating from the password vault code ...

7

In addition to the other answer Using asymmetric cryptography in the meters would have some benefits: it can make passive eavesdropping of meter/server communication useless, even to a party holding or able to use the server's private key; something not achieved with secret-key cryptography. it can ensure that any central key leak can not compromise the ...

6

A symmetric cipher design contest was started in Ukraine around 2006, and this cipher (in Ukrainian and Russian: Мухомор) was there. For specifications, look for "Applied Radioelectronics" journal "Прикладная радиоэлектроника", 2007, No 2. http://anpre.org.ua/?q=pre_2007_2 http://dspace.nbuv.gov.ua/bitstream/handle/123456789/61794/06-Dolgov.pdf

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

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

The scheme you describe is essentially same as the "SIV construction"* introduced by Rogaway and Shrimpton in their 2007 paper "Deterministic Authenticated-Encryption: A Provable-Security Treatment of the Key-Wrap Problem". This construction takes a PRF (such as HMAC) and a conventional IV-based encryption scheme (such as, say, a block cipher in CTR mode), ...

5

Alice also needs to first decrypt the symmetric key and then decrypt the message. It almost seems like a double work. Encrypting a short plaintext (i.e. the symmetric key) requires only one asymmetric (e.g. RSA) operation, while encrypting a longer message would in theory require many RSA operations. Suppose we want to encrypt a 1 MiB message. Using 2048-...

5

AES is a block cipher and would return wrong data when a wrong key is used. It only works on a single block of data (16 bytes). The default CBC mode of operation enables you to encrypt multiple blocks of data. The padding then enables you to encrypt plaintexts of arbitrary length. The padding has to be removed somehow after the decryption. You're seeing a ...

5

Let's say the plaintext is English text (or some language that uses the basic latin characters), encoded in Unicode. That means each byte represents one character, and because of the quirks of Unicode, the basic latin characters and typical punctuation marks all have a zero for the most significant bit. To attack your scheme, an attacker would look for ...

4

Would this help preventing brute force attacks? It would slow down an attacker and prevent them from trying as many password guesses. E.g. if you used 1000 rounds like in RFC 2898, you would reduce the number of guesses by a factor of 1000. Assuming you count dictionary attacks under brute force attacks, such attacks would definitely not be completely ...

4

First, a bit of background. If we refer to the size of an elliptic curve group as $n$, we select an elliptic curve with $n = hq$, where $q$ is a large prime, and $h$ is a small integer called the cofactor; it is typically either 1, 4 or 8. The values of $q$ and $h$ will be part of the curve definition. As you know, with straight DH, we agree on a point $G$...

4

If the keys are at least as long as the data (which is confirmed in the comments), and the keys are chosen randomly and independent of each other, no there is no way to get the data. Even if you had infinitely many encryptions. This is because this type of encryption, called the one time pad, is perfectly secure.

4

There is a simpler way: implement a stream cipher using the hash function, and use that to encrypt the plaintext. Probably the most used stream mode is counter (CTR) mode, which is normally defined for block ciphers. CTR mode works equally well with a PRF (MAC) as with a PRP (block cipher). It only uses the function as a one-way function; with a block ...

4

Some amount of known or controlled plaintext is clearly required for the attacker to get the block cipher output. Actually, that's not much of an issue; we can often get a reasonable amount of known plaintext from real encrypted messages. In fact, the known plaintext for each message doesn't have to be the same, and you don't have to have completely known ...

4

Password Based Encryption (PBE) is specified in e.g. RFC 2898 which specifies the "PKCS #5: Password-Based Cryptography Specification Version 2.0". Keys used for symmetric ciphers such as AES and Twofish should be fully randomized. Passwords, even strong ones, do not consist of randomized bits. So they need to be converted to ...

3

I have not seen a proof of theorem, but I'm guessing such results arise from basing the security of block cipher modes purely on their behavior as pseudo random functions. Another factor is that block ciphers are not pseudorandom functions (PRF), but pseudorandom permutations (PRP). That means that as you get close to the birthday bound you do not see the ...

3

Yes, the principle to use a common password and a unique salt per file with a key derivation function is a good and acceptable practice, as you generate the salt randomly and with the right size. The uniqueness of the salt guarantees a different password per file (actually one password per salt, so: do not reuse a salt, use a csprng). You forgot to mention (...

3

The point you highlighted (same plaintext and same key produce same ciphertext) is not a problem for a cryptanalytic point of view: you don't give any additional information to the attacker, but it is a weakness from a traffic analysis point of view. If the same ciphertext is stored in different locations or is broadcast multiple times on the network, an ...

3

Let's look at your requirements: have a large IV — specifically, one large enough that using a CSPRNG to generate a fresh IV each time is secure. Generally, IVs/nonces longer than 96 bits are thought to be okay for random generation. If it is at least 128 bits you can safely use it as long as you can a 128-bit block cipher like AES, because before you ...

3

In addition to the other answer. The "Steps of Hybrid Encryption" in the question really are steps of one form of hybrid encryption, built on top of asymmetric encryption. There are other forms of hybrid encryption (at least for the meaning of that in protocols), including some resistant to passive eavesdropping (attacks where the adversary can't send or ...

3

To randomly guess a single key from a 128-bit key space has a chance of 1 divided by the number of elements or $\frac{1} {2^{128}}$ where $2^{128}$ is the number of keys possible. To get ballpark figures to convert between base 2 exponents and base 10 exponents you can use the following trick: Because $2^{10} = 1024 \approx 10^3$ you can easily count the ...

3

Symmetric keys don't need to be in any particular format -- they're just a sequence of (pseudo)random bits. Most programming environments provide some sort of "secure random" mechanism (a CSPRNG). You can use this to acquire a byte array of the appropriate length (e.g. 32 bytes for AES256), which can be used as a key. Be sure to pass in the raw bytes, and ...

3

In general, no. Consider the following perfectly secret probabilistic encryption scheme. Encrypt exactly like a one-time pad. Then, with probability 1/4 add a 0-bit after the ciphertext, and with probability 3/4 add a 1-bit after the ciphertext. For decryption, first throw away the last bit, and then decrypt as in the one-time pad. The ciphertexts in the ...

3

GCM is authenticated encryption. As such, it is secure against chosen-plaintext attacks and against chosen-ciphertext attacks. Thus, there is no problem whatsoever with the adversary having access to an encryption oracle. It will not help it at all to break any of the encrypted messages.

3

RFC4868 is not the HMAC RFC, which is actually RFC 2104. 4868 refers to the use of HMAC within IPSEC, which is why there is a key length restriction. The maximum length key that can be used internally with HMAC-SHA256 is equal to the block size, 64 bytes or 512 bits. This can be useful in cases where the key is not full entropy such as the shared secret ...

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