Hot answers tagged aes
I think it's easier to split this into its component parts, and consider them as separate entities: AES and CBC. AES itself does not "basically consist of XORing together chunks of the block" - it's a much more complicated affair. Ignoring the internals of it for a moment, AES is considered secure in that without knowing the key, it's practically impossible ...
No, because the key is secret. The "block cipher encryption" block in the diagram scrambles the data depending on the key. The XOR in the diagram does not provide the security, the encryption does. The XOR and the IV are just to make sure the same plaintext encrypts as different ciphertext for each block.
Is it safe to use a part of the key as IV and what is best practice? In a word. NO. IV is a fundamental part of cryptography that forms part of the essential element of randomisation. The use of a non-cryptographically random IV that is static or otherwise predictable as part of your encryption process means that you are potentially weakening the ...
All modern encryption methods (AES, blowfish etc.) are designed to be much more secure than you seem to expect. Let us quickly look at some attacks which such ciphers are designed to be resistant against. Known plain text attack - In this case we assume the attacker has access to many plain text blocks along with corresponding cipher text blocks encrypted ...
The answer by Little Code is correct in that it is absolutely not safe to reuse part of the key as an IV, particularly if you intend to use the key to encrypt more than a single piece of data. HOWEVER: That is not what the code snippet you reference in your question is doing. Rfc2898DeriveBytes pdb = new Rfc2898DeriveBytes(password, salt); ...
Do not use SHA256 to hash passwords. SHA256 is a message digest algorithm. It is designed to be very fast. Use an algorithm which is intentionally designed to be slow and hard to implement in specialized hardware. Why? Because fast algorithms allow an attacker to brute-force a large number of passwords until they found one which works. "They'll still have to ...
it depends, but - generally - no. AES is a block cipher, so you're breaknig a thing by 256 bit blocks in your case. And 100KB is more than enough to guess a type of "what's inside", by MIME, for example, after that a task is a way more simplier
This is actually a quite tricky problem with no perfect solution. If the file system was one were data is written only once and written entirely sequential, a single CBC encryption all the way from the start of the media to the end would be suitable. You can do random access decryption of CBC, you just need to read one additional cipher block. This could ...
The IV has the same security requirements as the encrypted blocks. For CBC to work, you need to XOR the unencrypted data in the current block with the encrypted data from the previous block. Because there is no block before the first block (so no encrypted block can be obtained) an IV is used instead.
Absolutely. There is no risk from appending the nounce/iv to encrypted text.
Serval other softwares using AES 256 encryption support any key length such as a 10char insted of the 16. how is that possible (such as winzip's aes encryption)? the same way the other way. how can the encryption depend on the key strength when the key has to be 16 chars what i was thinking was if the passharse was less than 16 then fill the remaining ...
For encrypting data, it's generally recommended to store a random key and encrypt this with the appropriately salted password. This means that if/when the user changes their password, you only need to decrypt and re-encrypt their key, and not all their data.
KW allows you to establish a long term secret but still use a different CEK for each message, this is important for some use cases, but not all. In the case of using JWE to send a single message to multiple recipients who all have different long term keys, this is essential as you need to wrap the CEK multiple times once for each recipient. JWE supports a ...
I realize the post is from 2013, but I happened upon this post when researching a patch for the latest openSSL vulnerability announced 3 May 2016 (Info - https://www.openssl.org/news/secadv/20160503.txt). The recommended patch is TLS1.2+AES-GCM cipher suite. The latest browser on the latest OS should have support for AES-GCM at this point. If you'd still ...
Only top voted, non community-wiki answers of a minimum length are eligible