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.
Related
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
I would love to make my own data encryption method like Base64 and such. (preferably in Python.)
Would it be secure if I assigned "a" to for say a random number between 1-100 and a random letter or such. (for example 53f) and other letters are combinations and its random. But then how would I make a decoder, sorry for the long question haha. Thanks!
Do not start by making your own encryption method. Start by reading Bruce Schneier's Memo to the Amateur Cipher Designer.
Then write your own versions of the simpler existing ciphers: Caesar, Vigenere, (both of historical interest) RC4, Feistel. That will help you with the structure of ciphers, particularly RC4 -- a stream cipher and Feistel -- a block cipher framework.
Base64 is not a cipher, as has been pointed out. It is a useful exercise to write your own Base64 encoder/decoder, though most modern languages include one in their library anyway. That exercise helps you practice bit manipulations.
When you have done all that, find an implementation of AES that you are happy using. Any cipher you devise will not be as secure as AES.
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 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 5 years ago.
Improve this question
I have a list of numbers. I will be calling a service(let's say accountant service) which is going to perform some operation on these list of numbers and will return me the final result.
I don't want to pass my data in plain format. I want to encrypt numbers in such a way if service performs any arithmetic operation and return me the result, I will be able to decrypt it back with actual result.
Yes. You can use something called Homomorphic encryption, which "is a form of encryption that allows computation on ciphertexts, generating an encrypted result which, when decrypted, matches the result of the operations as if they had been performed on the plaintext." With this type of encryption, they can be Partially homomorphic or Fully homomorphic. A fully homomorphic encryption can support arbitrary computation (also called "bignum arithmetic" or "Arbitrary-precision arithmetic"), whereas partially homomorphic algorithms cannot. As stated on the cryptography stack exchange by user mikeazo in this thread,
ElGamal is a semantically secure, multiplicativey homomorphic cipher. Paillier is a semantically secure, additively homomorphic cipher.
The user also elaborates further and mentions a significant downside of this form of encryption:
Homomorphic ciphers typically do not, in and of themselves, do not provide verifiable computing. In words, you encrypt your data, send it to the cloud and let the cloud compute on it for you. How do you know the cloud performed the correct computation? To get this sort of guarantee, other machinery is needed.
In your case, you would be sending it through an (I am assuming) reputable API, so this may not be a concern of yours.
From my research, your best bet will probably be Gentry's cryptosystem. To use this (in a program), HElib should work fine.
In the future, crypto.stackexchange.com would probably be a better place for this type of question
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
I have a login and password that I need to store in my database. What is a safer way to encode them (I use AES algorithm): as one string with separator between login/pass, or as a two separate strings?
Encoding has to be reversable, so please don't mention hash.
Safety has not much to do with your choice. If you use AES with mode different than ECB and PKCS7/PKCS5 Padding you can either encrypt logins and passwords alone or logins and passwords seperately. It depends on wheather you will need a login without a password in your implementation. You will probably use the same key to encrypt both login and password. So splitting is by no means an additional security measure. If you woudl use some salted PKDF keys can be different for each record, but attacker still needs only to get the master password and a salt.
That's no any additional security in encrypting them together or separately.
However, you should also choose wisely cipher mode/initial vector - for CBC and CTR (and CFB?) input to encryption is xored with encrypted Initial Vector, so having the same vector for two encrypted passwords, xoring them would allow to get xor of original passwords, which can leak information.
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 1 year ago.
Improve this question
ctr mode makes it possible to use a block cipher as a stream cipher but how strong will be the encryption in this mode ?
Ultimately it depends what you mean by strong. For example from an encryption point of view, i.e. taking the ability of an attacker to decrypt your ciphertext without access to the key, it should be as strong as any other use of AES256 (there is some dicussion on differential analysis between individual cipher blocks with a known plain text but that would be a weakness of the encryption algorithm not of the CTR mode itself).
In the end whether CTR mode is appropriate will depends what you want to apply it to and how you implement it. A couple of things to bear in mind when using this mode would be:
The same nonce/counter sequence will create the same cipher stream therefore you must ensure you do not ever use the same values for a given key. Otherwise it might be possible for an attacker given a message with a known plain text to reuse the cipher stream to decrypt your current message).
As the stream cipher is XORed with the plain text it means that a 1 bit change in the ciphertext directly results in that bit changing in the decrypted data, therefore some sort of message integrity is paramount, most likely a HMAC so that an attacker cannot realistically generate the hash and correct that as well.