I know with RSA there are a few ways you can encrypt and decrypt data, meaning you can encrypt with either the public or private key (or both), and you can also decrypt with just a private or public key, or both.
With Triple Des, do you need both key and iv to decrypt? Or can you do it somehow with just a key? (public key?)
Being a symmetric algorithm, DES (and 3DES) uses a shared secret key. It doesn't have public keys.
And IV must be known to decryptor if this IV was used during encryption.
RSA is a public-key (or asymmetric) encryption algorithm – which means that there are key pairs of public and private keys, where you encrypt with one of them and decrypt with the other.
DES and Triple-DES are block ciphers. You use them together with a mode of operation to encrypt or decrypt a message – you use the same key for encryption as for decryption. This is known as a symmetric algorithm.
Some modes of operation (all good ones) need an initialization vector, so identical plaintexts don't lead to identical ciphertexts (and sometimes other weaknesses as well). Normally this initialization vector should be send/stored together with the ciphertext, it doesn't have to be secret. Depending on the mode of operation and the usage scenario, the IV should be used only once, be random, or non-predictable.
Also, nowadays you should not use DES (it has a too small key size to be secure). Triple-DES is okay, but much slower (and not more secure) than modern algorithms like AES.
3DES is no different than any other block cipher. If you are using a cipher mode which requires an IV, and you are not including the IV in the message header, you will need it to decrypt the message.
Related
In this example, the IV is known to both the Encrypt and Decrypt methods because they're in the same scope of the using(Aes myAes = AesCreate()) block. But when that is not the case, and it's never ever the same IV twice, how does the decryption routine get the IV?
I've been experimenting with RSA encryption in python (cryptography.hazmat.primitives.asymmetric). I have the following setup: On one end is the client with the public key sending encrypted data back to the server, which holds the private key. Right now I've got one-directional encryption working, but I'm wondering how you would (or if you should) securely decrypt a message client-side. I thought about just encrypting the private key and storing it, but then the password would appear in the code and expose the key to compromise. Is there a way to securely implement this with a key exchange? Or--the most likely alternative--is this a misuse of the protocol?
EDIT: Wanted to clarify that the possible concerns here would be that using RSA in this way might expose the private key on the file system or between the server and the client.
The normal way is for the server to encrypt the reply with the client's public key and client decrypt with its private key. This requires TWO RSA keypairs -- one for the client and one for the server, and requires each end to know the other's public key.
This need (along with high cost of PKE compared to symmetric encryption) is why PKE is normally only used for authentication and/or key exchange, and a symmetric cipher is used to actually encrypt traffic.
I'm a beginner to ECC crypto programming.
Does any one explain to me the difference with using ECDH for shared key exchange and use of ECIES by encrypting shared key with the public key of the receiver ?
I'm feeling that ECIES could also provide me secure key exchange as long as the private key is kept secret.
Thank you.
ECDH is a shared-secret derivation protocol. Two parties use knowledge of their own "private key" and their partner's "public key" to generate a shared secret. Generally the private keys are random numbers used for the key negotiation, and then discarded.
ECIES uses the same scheme as ECDH to generate a "shared secret", where one of the "private keys" is a random number, and its corresponding public key is included in the message itself. This means that the shared secret is derivable only by the person with the other private key. The message itself is then encrypted with some other scheme like AES, using the shared secret as the key.
If you're doing key negotiation, ECDH is the way to go. (Mandatory note: Of course, you shouldn't roll your own crypto for a production system, just use TLS.)
I have a Software that Encrypts message using AES , the random generated AES key is Encrypted by the receiver's public RSA key. now when I send the message to multiple users...
Sender Side :
Message is Encrypted by Random hashed (sha256) AES KEY
The AES key is then Encrypted many time and appended to the encrypted message using each receiver's public key.
the message has [ number for receivers, [list of encrypted keys], Encrypted message]
Receiver Side:
get the number of receivers
loop thru the appended encrypted keys and decrypt using your Private RSA. until you find the one intended for you. such that when he/she decrypt the key they get the AES Key.
3.decrypt the message using AES key.
Knowing that the key is of base 64 string which means it ends with '=', and of the length 256 because of the sha
the Question IS :
How Do i know (if I'm the receiver) that the Decrypted key using my Private RSA is correct Automatically ?
thank you in advance.
Two questions: Is the protocol you describe fixed, or might it be modified in any way? If it is fixed, which padding scheme do you use for RSA? PKCS#1 v1.5, OAEP or none at all?
If the protocol might be modified, you could use a cipher mode with authentication, such as EAX, CCM or GCM. If RSA key transport decryption fails silently, so will the authenticated AES decryption.
Use a variation of RSA-OAEP for the key transport that provides "plain text awareness" as described here: http://www.rsa.com/rsalabs/node.asp?id=2346.
There is no way to find this encrypted message belongs to which receiver.
But you can do is try to decrypt the message if the decrypt is successful then that is the Receiver
I am working on a third party client for Apple Remote Desktop. But I am stuck on its authentication process.
From Remote Desktop manual:
Authentication to Apple Remote Desktop clients uses an
authentication method which is based on a Diffie-Hellman Key
agreement protocol that creates a shared 128-bit key. This shared
key is used to encrypt both the name and password using the Advanced
Encryption Standard (AES). The Diffie-Hellman Key agreement protocol
used in ARD 2 is very similar to the Diffie-Hellman Key agreement
protocol used in personal file sharing, with both of them using a
512-bit prime for the shared key calculation. With Remote Desktop 2,
keystrokes and mouse events are encrypted when you control Mac OS X
client computers. This information is encrypted using the Advanced
Encryption Standard (AES) with the 128-bit shared key that was
derived during authentication.
Does anyone know where I can find a bit more technical information about the Authentication process in ARD? Such as which AES mode it uses and what initialization vector. Thanks
I ran into this exact problem recently. I couldn't find any detailed information beyond the high-level overview you mention, but I was able to figure out the technique based on my study of this C code from the gtk-vnc open source project. Basically, the steps are as follows:
Read the authentication material from the socket. A two-byte generator value, a two-byte key length value, the prime modulus (keyLength bytes), and the peer's generated public key (keyLength bytes).
Generate your own Diffie-Hellman public-private key pair.
Perform Diffie-Hellman key agreement, using the generator (g), prime (p), and the peer's public key. The output will be a shared secret known to both you and the peer.
Perform an MD5 hash of the shared secret. This 128-bit (16-byte) value will be used as the AES key.
Pack the username and password into a 128-byte plaintext "credentials" structure: { username[64], password[64] }. Null-terminate each. Fill the unused bytes with random characters so that the encryption output is less predictable.
Encrypt the plaintext credentials with the 128-bit MD5 hash from step 4, using the AES 128-bit symmetric cipher in electronic codebook (ECB) mode. Use no further padding for this block cipher.
Write the ciphertext from step 6 to the stream. Write your generated DH public key to the stream.
Check for authentication pass/fail as usual.
I don't have an Objective C implementation to share, but I have implemented this Java version which you may find useful to reference.
Not sure if anyone still needs this, but here's a Objective C implementation of the ARD authentication process that I cobbled together a few months back and released on Github a few days ago.
It's based loosely on David's (thanks!) Java implementation but uses OpenSSL's encryption functions for the MD5 hashing and AES 128 encryption steps.
There's also the TinyVNC library that also implements ARD authentication, but using the Crypto++ library for encryption functions instead.