Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 7 years ago.
Improve this question
According to CWE-329 NON-Random IV's allow for the possibility of a dictionary attack.
However, in the AES crypto example, golang docs use a non-random IV:
ciphertext := make([]byte, aes.BlockSize+len(plaintext))
iv := ciphertext[:aes.BlockSize]
Is this implementation safe or should I use a random function to get my IV?
It is secure, because the IV is filled from a Cryptographically Secure Pseudo Random Number Generator (CSPRNG) which is /dev/urandom by default and provided from the OS. From the ExampleNewCBCEncrypter function:
iv := ciphertext[:aes.BlockSize]
if _, err := io.ReadFull(rand.Reader, iv); err != nil {
panic(err)
}
Related
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 days ago.
Improve this question
Suppose you are told that the stream cipher encryption of the message “attack at dawn" is 6c73d5240a948c86981bc294814d (the plaintext letters are encoded as 8-bit ASCII and the given ciphertext is written in hex). What would be the stream cipher encryption of the message “attack at dusk" under the same key?
Stream cipher is a bitwise encryption, so changing one bit in plaintext will change one bit in ciphertext. So the ciphertext of "attack at dusk" should be 6c73d5240a948c86981bc294814k
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 2 years ago.
Improve this question
hey can someone answer these 3 questions please
Why middle block of 3DES is decryption rather than encryption? 2. Suppose an error occurs in a block of ciphertext during transmission from the sender to
receiver. What effect will be observed on the recovered plaintext at the receiver? 3. Inclusion of salt in UNIX password scheme is the difficulty of guessing password by 4096. However, the salt value is stored in pain-text as same entry as ciphertext. The salt value is known to attacker and need not be guessed. Then why is it asserted that salt increases security?
It's decryption with a different key to the first encryption.
Decrypting with the wrong key will further convolute the output.
3DES is a feistel cipher structure, encryption and decryption are symmetrical.
The reason triple DES is of the form EDE is for one reason, and one reason only: to make it compatible with single DES - thanks to #James Polk
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 4 years ago.
Improve this question
What would be the most space efficient way to encrypt some data such that the encrypted data satisfies any one of the following constraints:
1) Fits in 32 bytes or less of hexidecimal (64 characters)
2) Fits in 28 bytes or less utf-8 characters (28 characters)
3) Fits in a 64 bit unsigned integer
The goal is to encrypt some data (like user id + nonce) and store it publicly on a blockchain and then decrypt it later on a server. The storage requirements of the blockchain I'm using (Stellar memos -- https://www.stellar.org/developers/guides/concepts/transactions.html#memo).
I'm looking for space-efficient encryption algorithms, or some combination of encryption + lossless compression that could make it fit.
There will be two inputs to encrypt: a user id and a nonce -- let's just assume we can fit both inside of 25 characters.
Example:
encrypt("7863439|12343567") -> "385acd1ca0ab619b9f832025fa358b69"
decrypt("385acd1ca0ab619b9f832025fa358b69") -> "7863439|12343567"
Use AES-256 or Twofish-256 You will have 256 bit = 32 bytes. This fits your 1st requirement. Both are space efficient. Well it depends of course how you define "efficient".
Maybe you could use hashing instead of encryption. Hash your data and store it on a server. Finding input data that will collide with your stored hash is designed to be difficult. Use a strong hashing algorithm that outputs 32 bytes of data, and you're done.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
What is the IV in encryption used for?
Is this a valid example for encryption with IV? (Pseudocode)
Encryption->xor data with key, prepend IV to output
Decryption->just remove IV and xor the rest with same key
The IV (Initialization Vector) is designed to be random for each message so that two identical messages encrypted with the same key are not the same thus leaking information. The IV does not need to be secret so it can just prefix the encrypted message.
The point is that the IV causes the entire encrypted message to be different, adding it to the message is just one common way to make it available for decryption.
Consider the case where Alice sends Bob a message every day of where they will meet, either the mall or the post office. With the same key and IV eavesdropping Eve after noticing where they meet but not knowing which location can tell just be looking at the encrypted message without need to decrypt it. It could be "attack at dawn" or "attack at dusk".
The key can be pre-shared once and reused securely for many messages just by using a different random IV for each message.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
Let's say i have one plaintext and i encrypt it with different keys (each on its own). Is it possible to find the plaintext from these encrypted ciphers or how hard is it to resample the text?
Does this even make sense, especially in respect to asymmetric-encryption?
For example:
VALUE KEY CIPHER
"abc" + "key1" -> "izwer"
"abc" + "key2" -> "werio"
"abc" + "key3" -> "nbmdi"
"abc" + "key4" -> "oiuuw"
The best known example of an attack against asymmetric encryption with multiple keys is
Hastad's broadcast attack against RSA.
This is of course one of the motivations to use a properly designed padding scheme.