Are sufficiently large key sizes enough to deter quantum attacks for symmetric key ciphers such as AES?
121979
We know  speedup brute-force attacks two times faster in block ciphers (e.g brute-forcing 128-bit keys take $2^{64}$ operations, not $2^{128}$). That explains why we are using 256-bit keys to encrypt top secrets. But  on AES shows brute-forcing AES-256 take $2^{100}$ operations. Does this attack work with Grover's search to make AES cipher quantum unresistant?
48753
I've come up with this little routine for doing encryption using the SHA-2 (in this case SHA-256) hash function. As such it is a block cipher with a 256 bit (32 byte) block size and an arbitrary key length. It's easy to see that you could replace the hash function and get an entirely new type of algorithm.  I want to know if there are any problems, especially flaws, in this construction, and whether algorithms of this type have been studied.  Initialization with key:  $$ S_0 = H(k) $$  Encryption for plaintext blocks $P_1, \dots P_n$:  $$ S_i = H(S_{i-1})$$   $$ C_i = P_i \oplus S_i $$  Decryption for ciphertext blocks $C_1 \dots C_n$:  $$ S_i = H(S_{i-1})$$   $$ P_i = C_i \oplus S_i $$  Here is some sample C source code using SSL:  #include &lt;openssl/sha.h&gt;  struct sha_crypt_state {     unsigned char digest[SHA256_DIGEST_LENGTH]; };  void sha_crypt_set_key( sha_crypt_state *state, unsigned char *key, int key_length ) {     SHA256( key, key_length, state-&gt;digest ); }  void sha_crypt( sha_crypt_state *state, unsigned char *block ) {     sha_crypt_state temp;     SHA256( state-&gt;digest, sizeof(state-&gt;digest), temp.digest );     memcpy( state-&gt;digest, temp.digest, sizeof(temp.digest) );      for ( int i = 0; i &lt; sizeof(state-&gt;digest); ++i ) {         block[i] ^= state-&gt;digest[i];     } }  void sha_crypt_test() {     const char *key = "secret";      // prepare a test block     char block[SHA256_DIGEST_LENGTH];     memset( block, 0, sizeof(block) );     strcpy( block, "Hello, testing encryption!" );      // test encrypt     sha_crypt_state state;     set_key( &amp;state, (unsigned char *)key, strlen(key) );     sha_crypt( &amp;state, (unsigned char *)block );      // test decrypt     set_key( &amp;state, (unsigned char *)key, strlen(key) );     sha_crypt( &amp;state, (unsigned char *)block ); }
22689
I'm trying to generate a secret key to be used for HMAC SHA-256 signature processing. I've seen many sample of keys with variable length from 32 characters to 96 characters.  What is the ironclad rule for this key size?
34586
I needed some simple string encryption, so I wrote the following code (with a great deal of "inspiration" from ):      // create and initialize a crypto algorithm     private static SymmetricAlgorithm getAlgorithm(string password) {         SymmetricAlgorithm algorithm = Rijndael.Create();         Rfc2898DeriveBytes rdb = new Rfc2898DeriveBytes(             password, new byte[] {             0x53,0x6f,0x64,0x69,0x75,0x6d,0x20,             // salty goodness             0x43,0x68,0x6c,0x6f,0x72,0x69,0x64,0x65         }         );         algorithm.Padding = PaddingMode.ISO10126;         algorithm.Key = rdb.GetBytes(32);         algorithm.IV = rdb.GetBytes(16);         return algorithm;     }      /*       * encryptString      * provides simple encryption of a string, with a given password      */     public static string encryptString(string clearText, string password) {         SymmetricAlgorithm algorithm = getAlgorithm(password);         byte[] clearBytes = System.Text.Encoding.Unicode.GetBytes(clearText);         MemoryStream ms = new MemoryStream();         CryptoStream cs = new CryptoStream(ms, algorithm.CreateEncryptor(), CryptoStreamMode.Write);         cs.Write(clearBytes, 0, clearBytes.Length);         cs.Close();         return Convert.ToBase64String(ms.ToArray());     }      /*      * decryptString      * provides simple decryption of a string, with a given password      */     public static string decryptString(string cipherText, string password) {         SymmetricAlgorithm algorithm = getAlgorithm(password);         byte[] cipherBytes = Convert.FromBase64String(cipherText);         MemoryStream ms = new MemoryStream();         CryptoStream cs = new CryptoStream(ms, algorithm.CreateDecryptor(), CryptoStreamMode.Write);         cs.Write(cipherBytes, 0, cipherBytes.Length);         cs.Close();                     return System.Text.Encoding.Unicode.GetString(ms.ToArray());     }   The code appears to work fine, except that when decrypting data with an incorrect key, I get a CryptographicException - "Padding is invalid and cannot be removed" - on the cs.Close() line in decryptString.   example code:      string password1 = "password";     string password2 = "letmein";     string startClearText = "The quick brown fox jumps over the lazy dog";     string cipherText = encryptString(startClearText, password1);     string endClearText = decryptString(cipherText, password2);     // exception thrown   My question is, is this to be expected? I would have thought that decrypting with the wrong password would just result in nonsense output, rather than an exception.
35921
Suppose I want a strong 20-bit blockcipher.  In other words, I want a function that takes a key (suppose the key is 128 bits), and implements a permutation from 20 bits to 20 bits.  The set of permutations should be close to a randomly-chosen subset of size $2^{128}$ of all $2^{20}!$ permutations on 20 bits.  I don't want you to build a new blockcipher from scratch.  Instead, assume you have a "strong" blockcipher like AES (128-bit blocksize, 128-bit keysize) and use this to build your 20-bit cipher.   Of course, your construction should be practical (i.e., you should be able to run it in both directions with reasonable amounts of time and memory).
115825
Is there any pair of 128-bit strings M and K such that AES$_K$(M) = M?  If yes, how do I go about (efficiently) finding such a pair?
33556
At least it's my understanding that AES isn't affected by known-plaintext. Is it immune to such an attack, or just resistant? Does this vary for chosen-plaintext?
45185
For a software, I don't want the user to choose weak keys, so I plan to just read the needed number of bytes from /dev/random to create the needed secret keys. Is it safe to do so?
32272
The cipher AES-256 is used among other places in  across the Internet. It's considered among the top ciphers.  In theory it's not crackable since the combinations of keys are massive.  Although NSA has categorized this in , they have also recommended using higher than 128-bit keys for encryption.  So how secure is this cipher really? Should you assume the worlds top cracker-institutions are near or have cracked it already?
106463
I am developing a software with hybrid encryption (RSA-4096 and AES-256-CBC). The iv and key of an AES encrypted file will be RSA encrypted end exchanged through a different way than the encrypted file. Thats ok for me to this point.  I am thinking about where it is most easy to break the encryption of my own files and always come to the point where a key and iv guessing would take ages but is theoretically easy. It just takes time with the computing power we have today.  In my application the transfer of the encrypted file will not be possible if there are bits lost in any case.  Version 1: Since CBC is always based on the the pre block, why do I not just change the order of the blocks in the file and write a map together with the key and iv into the RSA part? Is this a stupid idea?  Version 2: Why do I not just replace a random character in each AES block with its "value" + 1 or so and write into my RSA a map of the chawed characters?  In my opinion in Version 1 the "guessing power" would be the "AES blockcount"*"time for a single file" and after that the order would sill be wrong. I have no idea what effort it would take to get the right order...  In the second Version it would be even to hard for me to calculate. It could be any bit in a block with a wrong value and a guessing of iv and key per block.  Does that make sense? Who knows about the computing power we will have in a few years. And I also don't want people to read the files in a few years ;-)
100917
I was reading about this in a cryptography book last night.  I have a hunch about this, but I can't quite put my finger on it.  I think this is a similar situation to an affine cipher, where the multiplication factor has to be relatively prime with the size of the alphabet in order for the function to be surjective.  Obviously for practical purposes, it would have to be $p^n$ where $p$ is the arity of the number system and $n$ is the bit width of a memory unit.  But is there also a theoretical basis for requiring that a Galois field be of size $p^n?$
62395
From a paper via Schneier on Security's  (emphasis mine):  In the case of AES-128, there is no known attack which is faster than the 2128 complexity of exhaustive search. However, AES-192 and AES-256 were recently shown to be breakable by attacks which require 2176 and 2119 time, respectively. While these complexities are much faster than exhaustive search, they are completely non-practical, and do not seem to pose any real threat to the security of AES-based systems. In this paper we describe several attacks which can break with practical complexity variants of AES-256 whose number of rounds are comparable to that of AES-128.  Is the implication here that AES-192 is stronger than AES-256? If so, in simple terms, how is that possible?  The attack exploits the fact that the key schedule for 256-bit version is pretty lousy -- something we pointed out in our 2000 paper -- but doesn't extend to AES with a 128-bit key.  Again, in simple terms, what does that mean? In practice, does this mean I should drop AES-256 in favor of its 128-bit counterpart, like Schneier recommends in the comments?  That being said, the key schedule for AES-256 is very poor. I would recommend that people use AES-128 and not AES-256.
7980
When using Encrypt-then-MAC with AES and HMAC by password, and given 128 bits of payload with the ciphertext to store a random salt, which would be more secure:   Using PBKDF2 with then entire 128 bit random salt and generating 512 bits of derived data to split into a 256 bit AES Key and a 256 bit HMAC key.   or   Using PBKDF2 separately for each key using two 64 bits salts to generate a 256 bit AES Key and a 256 bit HMAC key.    or    Better option?
90368
If I understand correctly in (unpadded) RSA the length of message M must be shorter than modulus n.  Encryption gives ciphertext that is also shorter than n.  Let's say I want to send a message of 2.5x length of n.  Is the split of message into chunks inferred somehow, or is that encoded somehow within ASN.1 keys? What are the different options/standards for this?  EDIT: Probably RSA is not used for messages longer than n but symmetric keys are generated with RSA and then they are used for longer messages?
76586
I came across the  family of ciphers for small domain input blocks. They cipher arbitrary block lengths: 32, 48 and 64, but their key size is 80 bits only.   Is 80 bits of key size considered safe against brute force attacks with current state of the art processors?
72071
Let's say that Alice and Bob complete a key exchange and then Alice uses that key k1 to encrypt a 256-bit key kaes1 and sends it to Bob. From there, Alice and Bob exchange a lot of messages back and forth, using AES-256 to symmetrically encrypt the data with the key kaes1.  Then, Charlie comes along and wants to participate, so Alice and Charlie complete a key exchange and Alice then uses that key k2 to encrypt the same original kaes1 and sends it over to Charlie. From there, Alice and Bob and Charlie now exchange a bunch of messages symmetrically encrypted with AES-256.  Eve has been listening in this whole time, and she has all the data, but none of the keys. Does Eve gain an advantage if she knows that kaes1 was the payload for 2 different messages encrypted with 2 different keys k1 and k2?
59037
I am a bit of a newbie to RSA encryption, so please be patient.  I understand that for a 4096 bit RSA, the numbers p and q should be prime. And to have the best security, the p and q should both be about 2048 bits long.  However, we don't have a way of generating and verifying a 2048 bit prime number with 100% accuracy. The implementation for prime generation that gpg uses goes through 64 rounds of miller-rabin which is enough to give a prime probability of $1 - 2^{-128}$.  Given that these primes are only probabalistically prime, what happens if we selected composite values for p or q?  Does the RSA algo run into any sort of problem?  My guess is that there will be no problem and RSA continues to function normally (encryption and decryption both) because, if there was a problem, we could use that problem as a way to detect that the numbers are not prime. This would give us a really fast way to verify extremely large prime numbers. I am guessing this is not the case.  So, my conclusion is that RSA works with prime or composite p, q... but using composite p, q makes it easy to break the encryption (because its easier to derive p, q from n).  Is this conclusion correct?