Hot answers tagged symmetric
8
There are two main reasons why asymmetric cryptography is practically never used to directly encrypt significant amount of data:
1) Size of cryptogram: symmetric encryption does not increase the size of the cryptogram (asymptotically), but asymmetric encryption does. If we take the example of RSAES-OAEP in PKCS#1v2 with a 1024-bit key and 160-bit SHA-1 ...
6
The Diffie-Hellman key exchange is a public-key technology. It is (by itself) not an encryption algorithm (or signature algorithm), though.
Here is the basic function: (All calculations here happen in a discrete group of sufficient size, where the Diffie-Hellman problem is considered hard, usually the multiplicative group modulo a big prime (for classical ...
6
Symmetric encryption and asymmetric encryption algorithms are built upon vastly different mathematical constructs.
In typical symmetric encryption algorithms, the key is quite literally just a random number in $\left[0 .. 2^n\right]$, where $n$ is the key length. The strength of the key is based upon its resistance to brute-force attacks, where an attacker ...
6
A block cipher is a family of permutations where the key selects a particular permutation from that family. With a tweakable bockcipher both key and tweak are used to select a permuation. So tweak and key are pretty similar.
The main difference are the security and performance requirements for a tweak:
Changing a key can be expensive, changing a tweak ...
6
It is probably not the case of your example, but in some sense "asymmetric hash functions" do exists: they are called trapdoor hash functions (or also chameleon hash functions).
Very briefly, they are collision resistant only if you don't know their trapdoor secret key.
Such functions take 2 arguments (instead of the usual one), and the second argument is ...
6
Neither of those really represent how confusion might get introduced into an encryption function. Confusion typically gets introduced during the computation of the ciphertext, not before or after.
As an example, we can look at AES. AES is a substitution-permutation network. This means the encryption is done by doing several rounds of substitutions and then ...
5
I think this is generally not a good idea, for two reasons.
First, do not generate a key as a hash of a passphrase. Where possible, you should try to avoid deriving cryptographic keys from passphrases, as passphrases rarely have enough entropy to make a secure crypto key. If you must derive the crypto key from a passphrase, then be sure to use PBKDF2 (or ...
5
Hashes like SHA-x are symmetric and unkeyed. I have never heard of asymmetric hashes.
Your question is based on a misunderstanding. You can implement computations in an asynchronous fashion, where you request some computation, then your thread is free to do something else, and at some later point when the computation is finished you do something with the ...
5
If your alphabet (set of all possible characters) has size $s$ and your password has length $l$, a randomly generated password has a strength of $\log_2s^l = l\cdot\log_2s = l\cdot\frac{\log_{10}s}{\log_{10}2}$ bits.
This means if you want to create a 128-bit password using a 80-character alphabet, you need at least ...
4
We do not really know how to do RSA encryption of messages which span multiple blocks. At least not securely. The problem is already hard for block ciphers (see all the defined modes of operation).
Also, the worst performance issue with arithmetic cryptography like RSA is not about CPU, but about size. When you encrypt a piece of data with RSA, you get some ...
4
Well, to figure out this sort of thing, it's easier if we work backwards.
So, we start at the back (the fact that we can store up to 512 characters in a database field), and consider how much binary data we can store. Well, base-4 takes 3 bytes of binary data, and encodes it in 4 bytes of base-64. Thus, we can store 3*(512/4) = 384 bytes of binary ...
4
If you go through the math, it appears that exactly the expected amount of ciphertext expansion is happening. Here's what's happening:
The GCM takes the plaintext as a byte string of size N, and generates a ciphertext which is a byte string of size N+28, where 12 of the 28 is the nonce, and the other 16 is the authentication tag.
Then, that octet string ...
4
Yes, this is a fine approach. This sort of technique is known as "key separation".
Since your master key is a cryptographically secure key, you do not need to use a large iteration count. Also, you could use any PRF, in place of PBKDF2. (The iteration count is normally used if you are applying PBKDF2 to a passphrase, instead of a cryptographically secure ...
4
Your problem is that if you encrypt two messages which start the same (and change at some point later on) the beginning of the ciphertext will be the same in CBC mode when using the same IV.
Normally you should change the IV every time you encrypt a new message. This is precisely what the IV is meant for - achieving IND-CPA (semantic) security which ...
3
Yes, these are key derivation functions basically deriving a shared secret from information identifying the two parties (like their respective MAC addresses) and nonces and other session communication relevant information. See e.g. the PBKDF2 derivation function.
3
GCM mode is best, as it can not be attacked using padding oracle attacks, which are much more common than commonly thought. It is also the only one providing integrity protection, something that is certainly much overlooked.
Make really sure your NONCE is random though, or use one that is uniquely defined (even in time) within the database.
...
3
I would say that CBC+HMAC mode is the best of the three (although not the fastest), because of the various security requirements on the IV/nonce.
For GCM and CTR, the counter must be unique, for every pair encryption key/plaintext. I assume the key will be always the same. Uniqueness is very difficult to securely achieve in practice. If you rely on some ...
3
There are two forms of entropy here at work. First there is "uncertainty" entropy from the user password which is typically very low (on the order of 20 to 40 bits for most passwords out there). And then, there's "computational" entropy, which is artificially obtained by forcing an attacker to do work to calculate keys.
Essentially, if you run your KDF for ...
3
The answer to your question is yes this is possible, but if we don't use assymetric cryptography, we need an alternate source of assymetry. One option is using time-delayed schemes. In such schemes, the key for the MAC is not initially disclosed, but only after some time interval.
See here for TESLA that accomplishes this. TESLA has a drawback in that it ...
3
Would a “Triple AES” (in the sense of how Triple Des works) serve for a dramatic increase in safety?
Your first option:
Encrypted(Input) = AES256(key2, Serpent(key1, Input))
suffers from a textbook meet-in-the-middle attack. It only gives you one additional bit of security over AES alone / Serpent alone. Not a good choice if you're aiming for extra paranoia.
2
Different modes of operation have different requirements. For example, the IV for CBC mode should be generated with a CSPRNG, where as the IV for CTR mode just needs to be unique for each encryption. In terms of cryptography, the 'random' functions found in many languages are more predictable than you might imagine.
That being said, there's absolutely no ...
2
Symmetric encryption is generally faster than asymmetric encryption. That is the basic reason to use symmetric encryption with larger amounts of data. The time difference between the two methods will increase linearly as the amount of data increases.
From Wikipedia on computional cost of Public-key cryptography:
Computational cost
The public key ...
2
IMO AES-CTR+HMAC is more secure than AES-GCM. The most significant difference is that AES-CTR+HMAC relies on the nonce for confidentiality but not for integrity. AES-GCM on the other hand relies on the nonce for both. So nonce failures are much more severe with AES-GCM.
The main advantage of AES-GCM is that it's significantly faster.
2
First off, you are still missing some information. What encryption mode will you be using? What key are you using for the HMAC?
That said, my answer is no. This isn't a good way. The reason being is that unless you are a professional cryptographer, you shouldn't design your own cryptographic protocols/methods. There are too many ways to introduce ...
2
Sure. Needham-Schroeder (e.g., Kerberos) solves exactly this problem. If each party shares a key with a trusted party Trent, then it provides a protocol that Alice and Bob can use to establish a session key good for use for encrypting traffic between the two of them. Kerberos v4 uses this in a purely symmetric-key setting: no asymmetric (public-key) ...
2
As @fgrieu mentioned, what you're after is FPE. The papers he linked deal with FPE on a very small domain, but it looks like you're interested in encrypting longer strings.
For that, you need a wideblock cipher. Unlike traditional blockciphers, these typically allow different input lengths, which is a plus. They meet your criterion of not revealing shared ...
2
You are inventing your own protocol. Don't do that! You're likely to get something wrong.
Instead, use SSL. You can use SSL with a server cert and a client cert. That solves exactly this problem; each party can verify the public key of the other end of the communication and verify they're talking to who they want to talk to. If everything checks out, ...
2
Here's a possible scenario:
1) Your password is put through a slow KDF such as Scrypt. The output of Scrypt can be configured to take a long time to calculate, and as such, can mitigate the risk of brute-forcing passwords. See here.
2) The output length of Scrypt is also configurable. So assume that half of the output becomes the encryption key for ...
2
What you want is basically impossible in this way. The crux of the matter is that if you want your application to access the encrypted data, your application needs to have the key in some shape or form.
Due to the limitations you mentioned, this key needs to be on the client machine, in the application's code or data files.
There are several ways to hide ...
2
Have you considered using Shamir's Secret Sharing algorithm?
First, Bob encrypts the message with a symmetric algorithm. Then, he divides the secret key into four parts using SSA such that it requires three parts to decrypt (a $(3,4)$ threshold). Bob then distributes one part each to Alice and Mark, and two parts to Jim.
When Alice wants to decrypt, ...
Only top voted, non community-wiki answers of a minimum length are eligible
