Hot answers tagged encryption
21
AES is an algorithm which is split into several internal rounds, and each round needs a specific 128-bit subkey (and an extra subkey is needed at the end). In an ideal world, the 11/13/15 subkeys would be generated from a strong, cryptographically secure PRNG, itself seeded with "the" key.
However, this world is not ideal, and the subkeys are generated ...
17
By definition you cannot encrypt values greater than the modulus in RSA, because the plaintext is immediately reduced modulo $n$ which loses information. This is because textbook RSA works in the $\mathbb{Z}/n\mathbb{Z}$ congruence ring, so from RSA's point of view, as long as two values have the same remainder modulo $n$, they are effectively equivalent. So ...
13
The algorithm (now reasonably clear) is reminiscent of a block cipher in CFB mode, with $random$ as the IV (which can be public), $secret$ as the key, and MD5 used as keystream generator instead of the block cipher.
Decryption works as in CFB:
$$M_1 = C_1 \oplus \operatorname{MD5}( secret||random )$$
$$M_n = C_n \oplus \operatorname{MD5}( secret||C_{n-1} ...
11
A few observations:
RC4 suffers from related key attacks. This means your idea of concatenating a 224 bit key and a 32 bit IV is not a good idea. You should rather use $\operatorname{SHA-256}(Key||IV)$
Remember that a (Key, IV) pair must not be reused, ever.
A 32 bit IV can work if it's a counter, but IMO such a scheme is unnecessarily fragile. I'd rather ...
10
It's not a security problem but a necessary feature. It's not an exact science to distinguish a "good decryption" from a "bad decryption". What if the user had encrypted random data? you would not be able to figure out if the key is correct or not from that sole information, since in both cases the decrypted output would look completely random!
Similarly, ...
9
Well, your definition of entropy is known as Kolmogorov complexity, and it's not so much that it is incorrect, as it is that it is inapplicable to what gzip does.
For example, the value $\pi$ can also be generated by a short program; however, if you attempt to compress a 2.2Mbyte sample of the binary expansion, you'll also find that gzip will also not be ...
9
The reason why you see that is because Camellia is the highest-preference cipher in NSS (Chrome and Firefox). Servers that support Camellia and use the client-preferred cipher suite will use Camellia.
NSS's rationale for this ordering is:
National ciphers such as Camellia are listed before international
ciphers such as AES and RC4 to allow servers ...
8
I can immediately think of four reasons:
They're both not using AES256. I see in the Obj-C document a direct statement that they are using AES256 (unless you deliberately change it), I don't see any statement in the Visual Basic document that says what key size they're using (unless that's what they mean by "Block Bits").
Different keys. AES256 takes a ...
8
The requirements for an IV depend on which encryption algorithm you are using (AES is not an encryption algorithm by itself, since it can only act on 16-byte strings, but it can be used as a building block in a variety of different encryption schemes), specifically on the mode of operation.
Roughly speaking, the role of the IV is to insert some "new" ...
8
For symmetric algorithms (like AES or DES or RC4 -- but not for RSA or ECDSA), a key is a sequence of bits, such that any sequence of bits of the same size is a potential key. So longer keys means more possible keys.
Exhaustive search is about trying all possible keys until a match is found. It is an absolute limit to the strength of an algorithm: ...
8
Enigma is not a Feistel cipher. A "Feistel cipher" is a block cipher with a specific structure, namely the whole business with the two halves, the combination of one half with a (one-way) function of the other half and a reversible operation (e.g. XOR), and the swap. See the Wikipedia page which has nice schematics.
So considering Enigma as a kind of ...
8
If you look at the CBC diagram, you'll see that having a fixed IV is equivalent to having the first ciphertext block become the IV. If your cipher is a good pseudorandom permutation, then what you are doing does work, if and only if all timestamps are unique such that the "new IV" is unique and unpredictable.
And in fact, if you do not use the ...
8
Yes, this thinking is correct; there is no requirement that the public exponent $e$ to be random. After all, it doesn't matter whether $e$ can be guessed by an attacker; we'll be including that value in the public key anyways.
Common practice is currently to use the fixed value $65537 =2^{16} +1$ for $e$. Any odd value of $e > 1$ will work; however, ...
8
It's not clear from your decryption what the algorithm is used for.
But you should be aware that while at first glance it provides privacy : it's a weird mode CFB with md5 used as a block cipher ; it doesn't provide authenticity.
A simple bit flip of the ciphertext will result in the corresponding bit being flipped in the plaintext and such a bit flip ...
7
Vanilla textbook RSA does not include "padding and stuff", the term "textbook RSA" generally refers to simply encoding a plaintext message as an integer and raising it to an exponent. Implementing this is pretty easy, just follow the steps outlined on Wikipedia. You can easily translate those steps into some given programming language.
Based on the rest of ...
7
How can I determine whether my method is cryptographically correct?
Well, that depends quite a bit on what your primitive does, and what security properties you claim for it. As for examples of security properties, you might claim it does privacy (someone without the key cannot determine anything about the plaintext) or integrity (if someone without the ...
7
No, RC4 is not completely broken. It is possible to use it properly. It's just not very likely that an average developer will do so.
RC4 is not a good choice for new systems. It is tricky to use properly. There are some serious pitfalls which, if you're not an expert cryptographer, can bite you in the butt. In fact, if you take a quick look in the ...
7
It is possible to build a block cipher out of a great many things. If you want to use a hash function, the classic trick is to follow a Feistel structure, which is, incidentally, the same kind of structure than what DES uses.
The schematics on the Wikipedia page are quite clear; you would use the hash function for the "F" part, which combines one (sub)key ...
7
The security of that approach is equivalent to that of normal CBC.
Your scheme with first plaintext block $IV^\prime$ is clearly identical to normal CBC with $IV=AES(IV^\prime)$. Since a block cipher is a permutation over a block, a uniformly random first plaintext block will lead to a uniformly random IV for normal CBC.
A ciphertext produced with your ...
7
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 ...
7
No, the public and private exponents will never be the same for real (that is, not toy) RSA keys.
The public exponent is almost always be deliberately chosen as a small value (with 65537, 3 and 17 being the most popular choices). In contrast, the private exponent will always be a huge value; always at least $(p-1)/e$ (where $p$ is the larger prime factor ...
7
In this context 'security margin' is a measure for how much better we need to get at analyzing a cipher to break it. Such advances in cryptoanalysis require new ideas of how one might attack a cipher. Thus estimating how strong a cipher is, is hard.
Ultimately we can only tell something is broken, after we've broken it.
We typically look at a few ...
6
It very much depends on the encryption scheme you are using.
In a deterministic encryption scheme, the same plaintext is always encrypted to the same ciphertext (when using the same key of course).
This indeed causes a security problem for all deterministic schemes. I.e. no deterministic scheme can be IND-CPA secure.
If you take a look at the IND-CPA game, ...
6
Yes, this is one case where ECB mode is secure.
It can be shown to be secure trivially from the indistinguishability assumptions of AES; that AES with an unknown key cannot be distinguished from a random permutation. If the plaintexts are all 16 bytes long, then in ECB mode, this directly means that the ECB mode encryption of those plaintexts are ...
6
Yes, simply encrypting each 16-byte block with AES-128 will insure their confidentiality if they are all different, w.r.t. to an adversary that can't break AES (nitpick: given that AES is an even permutation, we should also assume that more than two plaintext/ciphertexts pairs remain unknown, but that's a practical certainty). That use of AES can be named ...
6
For the 3rd proposal, see my comment to the question for the issues/questions I have regarding there.
For the 2nd proposal, basically what you are proposing is using an IV with a stream cipher. The IV in this case being the hash of the file which would have to be shared in order to decrypt. In theory, it is a good idea. In practice, however, the track ...
6
The CBC IV attack does more than that.
If I guess the plaintext corresponding to any ciphertext block I've seen before, and can predict a future IV, I can verify my guess by submitting a suitable message to be encrypted with that IV. Obviously, that could be bad if, say, I knew the plaintext to be either "yes" or "no", and only needed to find out which one ...
6
All the know problems have been solved and currently there is, at least, one practical and secure Mental Poker protocol.
Check this patent application:
METHOD AND APPARATUS FOR EFFICIENT AND SECURE CREATING, TRANSFERRING, AND REVEALING OF MESSAGES OVER A NETWORK
Application number: 13/086,208
Publication number: US 2011/0202766 A1
Filing date: Apr 13, ...
6
No. AES-256 is not weaker than AES-128. Absolutely not. And I disagree with the the advice that you should avoid AES-256.
The attack against AES-256 is a related-key attack, which is irrelevant to most real-world uses of AES-256. Related-key attacks only become relevant if you use the block cipher improperly, which is not something that you ought to be ...
6
This seems a strange question to ask. Is it for an assignment or are you trying to select the best mode for a particular application? Regardless:
ECB does not use an IV.
CTR has a nonce value, which could be considered an IV. A bit error there will produce an entirely different key stream for every block.
CBC and CFB will corrupt the first plaintext block, ...
Only top voted, non community-wiki answers of a minimum length are eligible
