Hot answers tagged

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


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

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


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

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

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


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

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

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

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

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


3

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


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

When using symmetric encryption is it important to compress the data first? No, not really (unless you're concerned with bandwidth usage). On the other hand, compressing the message can leak data (for example, how compressible the data is). Could it be the case for some ciphers but not for others? No, or at least, not for any cipher that we would ...


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

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

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


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

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


3

256-bit confidentiality Let's assume that we're using AES256-CTR and a 256-bit hash. A new 256-bit key $S$ is derived for each message. Since AES256 requires a 256-bit key, there are no extra bits in $S$ available for use in the nonce, suggesting that a constant nonce is used. I believe this is vulnerable to a multi-target attack. The first block of ...


3

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

Just use AES. It's hardware-accelerated and implementations have had ages to have flaws discovered and patched. More strongly, just use GPG to encrypt data at rest and just use TLS (>= 1.2, with appropriate AEAD ciphers) for data in motion. "If you're typing the letters A-E-S into your code, you're doing it wrong." Anything you build yourself is infinitely ...


2

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



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