Is a stream cipher algorithm (Encryption) has to be always symmetric? Wikipedia has mentioned it but without a reason. This site also portrays some information about it, but not clearly why only symmetric keys are used to encrypt stream cipher but not asymmetric?
I remember that the teacher explained in class that the encryption and decryption speed of asymmetric ciphers is relatively slow, and stream encryption requires high speed, which may be one of the reasons.
You can check here, Salsa20 has 408MB/s and 4.3 cycles per byte, I do not think any asymmetric ciphers can reach this speed, you have to exchange key everytime you want to send any infomations, the same key cannot be encrypted twice in cryptography.
Related
I have been working to create an RTP/RTCP client and server implementation as a project. I have hit a block when it comes to parsing incoming packets because I am having trouble understanding the encryption method. I have read RFC 3550 several times. Section 9 explains confidentiality and security. I've read about DES-CBC mode here.
Observations I've deduced about encryption
RTP/RTCP packets are encrypted as a unit, meaning ALL bytes are encrypted
Encrypted RTCP packets are prefixed with a 32-bit random number
Encrypted RTP packets are randomized by the timestamp and sequence number
DES-CBC is the default mode
DES-CBC mode requires a 64-bit key
DES-CBC mode requires a 64-bit initialization vector (IV)
DES-CBC has a block size of 64 bits
What I'm confused about:
DES-CBC states that it uses the "Privacy Enhancement for Internet Electronic Mail" (PEM) protocol, but the RTP RFC makes no mention of this. In addition, the encryption diagrams do not include any PEM headers or elements.
Diagram
UDP packet UDP packet
----------------------------- ------------------------------
[random][RR][SDES #CNAME ...] [SR #senderinfo #site1 #site2]
----------------------------- ------------------------------
encrypted not encrypted
So my questions are:
Where does the key come from or what header elements make up the key?
What is the initialization vector for RTP/RTCP?
How do I parse an encrypted packet vs an unencrypted one?
Does RTP/RTCP use the PEM protocol? If so, how?
DES-CBC is a way for encrypting data and it can be used for all different protocols that need it's data to be encrypted.
Where does the key come from or what header elements make up the key?
Encryption keys are generated during connection initialization(at connect time) and can be generated using different ways but generally using Public key cryptography(ex: RSA and DH) and using certificates to prevent MITM attacks which is where the PEM standards are used.
What is the initialization vector for RTP/RTCP?
The IV(initialization vector) is randomly generated number that will be used to ensure that same plaintext will not be encrypted to same ciphertext if using same key (That's why it's Random).
How do I parse an encrypted packet vs an unencrypted one?
For encrypted packets you decrypt first using key(SECRET) you got at connection time then use IV which is sent with data packets(NOT secret) to reverse encryption process. For unencrypted packets you just parse the data since there is no KEY and IV data is just plaintext.
Does RTP/RTCP use the PEM protocol? If so, how?
PEM is not protocol in the sense as network protocols such SSH. This definition I think is accurate enough from wikipedia
Privacy-Enhanced Mail (PEM) is a de facto file format for storing and sending cryptographic keys, certificates, and other data, based on a set of 1993 IETF standards defining "privacy-enhanced mail.
so if your client is using encryption there is a very big chance that it will be using PEM standards for symmetric key initialization.
NOTE: timestamp and sequence number are different from IV these fields are RTP header fields which can serve a similar purpose but they are different from CBC mode IV.
I'm expecting to cipher a string, from a client side (using aes-256-cbc and a Secret-Password already known by both server & client).
And then I'd like to decipher it (on the server side).
I have a code which does work just fine (functionnaly speaking). But it seems I need to send the IV vector from client to server.
I currently did it like this :
00000000000000000000000000000000.JAPQElUAxxxxxxxxxxxjTgJAPQElUAfgydvbY=
So, on the server I split the payload with a "dot" as separator and consider the first item to be the vector.
I believe this is not good to sendthe IV like this.
Would you please help me to understand how should it works?
In CBC encryption mode sending the IV without encrypted is normal and there is nothing to worry as long as the IV is unpredictable. See this question Why is CBC with predictable IV considered insecure against chosen-plaintext attack? from Cryptography.
A common way to send the IV is prepending it to the ciphertext. The libraries, in general, were designed to extract first 16-byte or enable offset in the byte-arrays.
CBC mode of operation is outdated. It has many problems as padding oracled attacks. You should use better alternative Authenticated Encryption (AE) modes as AES-GCM and ChaCha-Poly1305 which does not need padding. Also, in AE you will have confidentiality, integrity, and authentication where CBC only supports confidentiality.
AS modes provide an Authentication Tag that you will need to transmit with the IV. The usual practice; prepend the IV and append the tag to the ciphertext.
IV || Ciphertext||Tag
From what I can tell TLS works using both symmetric and assymmetric encryption.
The assymmetric schemes are used to exchange keys but when and what symmetric schemes are used?
The asymmetric schemes are used to exchange keys
and digital-signatures.
The symmetric schemes are used to data transfer with the agreed symnetric key during the key-exchange.
This is called Hybrid cryptosystem.
Yes you are right. Asymmetric algorithms are usually slower than the symmetric algorithms. However, symmetric algorithms require a shared secret key to encrypt and decrypt messages. Therefore, TLS allows the client and the server exchange a shared secret key using the asymmetric mechanism. Without an asymmetric algorithm, there is no way the shared secret can be exchanged between the two parties in a secured way. Once both the parties have the shared secret key, all subsequent communication between the client and the server are encrypted using the symmetric algorithm which is much faster than the asymmetric algorithm.
At a very high level, the steps in establishing a TLS connection looks like this:
Client -> Requests for secured session
Server -> Sends certificate & chain certificates
Client -> Verifies certificate
Client -> Generate random key for symmetric encryption
Client -> Encrypts the generated key with the server public key and sends the encrypted value to the server
Server -> Decrypt the client sent key with its own private key
Here onwards all subsequent communications between the server and the client will be encrypted using a symmetric algorithm.
Which specific algorithm will be used is determined by the cipher suites supported by the server and the client. During the connection setup, the cipher suite to be used is determined by the client preference.
A typical cipher suite name looks like this:
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
Here
ECDHE - Key exchange algorithm
ECDSA - Digital Signature algorithm used for signing the key
AES_128_GCM - Block cipher and mode with 128 bit key
ECDHE stands for Elliptic Curve Diffie Hellman Ephemeral. The Elliptic variant (the first E) is used for performance, whereas the Ephemeral variant (the last E) is for forward secrecy. Forward secrecy means that if an attacker keeps recording all the communications over TLS and at a later point of time somehow gets hold of the private key, he/she cannot decrypt the past recorded communications.
ECDSA is used for authenticating (verifying the integrity of) the shared secret. ECDSA is weaker and slower than the other authentication algorithms like HMAC. Yet it is used for shared key authentication because it does not need the verifier know the secret key used to create the authentication tag. The server can very well use its private key to verify the integrity of the message.
AES_128_GCM - Once a common secret key is shared between both the parties (usually a browser and a web server), a symmetric block cipher algorithm is used to encrypt the message exchanges between the parties. In this particular case, the block cipher AES with 128 bit key and GCM authentication mode is used.
If you open a HTTPS website in a browser, you can see the cipher suite used using the browser utilities. For e,g, in Firefox you can see the details under the Security tab in the Page Info, as shown below:
Hi
I know a basic rules on https!
I know there is private & public key, and public key is for encryption and private key is for decryption!
Now I have questions:
* - IF I know the public key why I cannot decrypt data, Surely it's related to private key!!!
*- And does https protocol encrypt all data or only data that sent by client??
for emxample, If i go to gmail.com, html codes are encrypted or not?
now if answer is yes(and HTML codes are encrypted) how my browser can decrypt it and others can't??
If no, why we should use it for example for downloading backup of important data?
Okay, a couple of points of confusion here.
First, HTTPS isn't actually encrypted with a public/private key scheme -- technically, "asymmetric encryption." It's instead encrypted using a symmetric encryption -- one of several, actually -- with a session key that's established through an algorithm like Diffie-Hellman key exchange.
The result is that the encryption is carried out through a one-use key that's computed as part of the handshake setting up the SSL connection.
The Wikipedia article on Transport Layer Security (SSL was really a proprietary term from Netscape) is reasonably decent.
If you could get that key, you could indeed decrypt the data, but since the usual key now is 128 bits long, you have roughly 1 chance in 2128 of getting it right -- or, in another way of looking at it, you can expect to take about 2127 (170141183460469231731687303715884105728) tries before you'd find the key.
But second, asymmetric encryption does come in one way, however. When you're establishing an SSL connection, the host provides an X509 certificate to identify itself; that's so someone can't hijack DNS and make themselves appear to be paypal.com instead of Vlad's Cut Rate Hacking. The X509 certificate is signed using a public/private key pair: the signature is hashed using the private side of a trusted providers key -- say VeriSign. They provide the public side, which allows you to confirm that the certificate was indeed encrypted by VeriSign. That confirms the authenticity of the cert.
Public Key encryption systems are based on One Way Functions; functions that are far easier to compute in one direction than in the other. There are two common choices of one-way functions for public-key cryptography systems: Large integer factorization and Discrete Logarithms.
There are no mathematical proofs that large integer factorization doesn't have easy solutions: however, several decades of intense research hasn't found any polynomial-time algorithms. (Not that one would necessarily be fast, just that finding one has been a good long-term goal.) The RSA cryptosystem safety is based on the difficulty of factoring large primes.
There are mathematical proofs that solving discrete logarithms is very difficult. The El Gamal and Diffie-Hellman algorithms rely on discrete logarithms for their safety.
The public key mechanisms are only part of actual deployed solutions though. Public Key systems are usually used for digital signatures and for negotiating a session key that is used with a symmetric cipher. Symmetric ciphers are far faster, much safer to use on plain text with patterns, and are an integral portion of modern communications privacy and integrity.
Now, to directly address your questions :)
IF I know the public key why I cannot decrypt data, Surely it's related to private key!!!
They are related. And you could find one given the other. But the computational complexity of finding one is currently so much worse than generating new public / private key pairs, the key itself should have no value by the time you have cracked it. (Years for 'smaller' keys, probably millennium for 'larger' keys. Trouble is, the definition moves around. :)
And does https protocol encrypt all data or only data that sent by client?? for emxample, If i go to gmail.com, html codes are encrypted or not?
HTTPS itself encrypts everything in both directions. HOWEVER, some web sites will use unencrypted http for images, css, javascript, and https for the HTML that actually contains the user data. This is because serving unencrypted content is much faster than serving encrypted content. It is also very unsafe, because most of those types of contents can be replaced while in-flight, allowing intruders to modify the browser's DOM or inject other new code, that lets them get access to the private data. Most browsers complain about mixed SSL/TLS and unencrypted content, so hopefully not many sites do this.
how my browser can decrypt it and others can't?
During the SSL/TLS handshake at the start of the session, the server and browser negotiate a new session key that will be used for the session. All the traffic between browser and client are encrypted with the session key, and as a result of the way the SSL/TLS session is created, only the client and server know the key:
https://www.rfc-editor.org/rfc/rfc5246#page-64
8.1.1. RSA
When RSA is used for server authentication and key exchange, a 48-
byte pre_master_secret is generated by the client, encrypted under
the server's public key, and sent to the server. The server uses its
private key to decrypt the pre_master_secret. Both parties then
convert the pre_master_secret into the master_secret, as specified
above.
8.1.2. Diffie-Hellman
A conventional Diffie-Hellman computation is performed. The
negotiated key (Z) is used as the pre_master_secret, and is converted
into the master_secret, as specified above. Leading bytes of Z that
contain all zero bits are stripped before it is used as the
pre_master_secret.
Note: Diffie-Hellman parameters are specified by the server and may
be either ephemeral or contained within the server's certificate.
IF I know the public key why I cannot
decrypt data, Surely it's related to
private key!!!
Yes the are related, but to determine the private key from the public one would require solving a computational hard problem that is factorize a prime large number.
For telling it in simple words, you can do it, but the time it would require with the actual technologies is too long.
I am having an application where I have to send several small data per second through the network using UDP. The application needs to send the data in real-time (no waiting). I want to encrypt these data and ensure that what I am doing is as secure as possible.
Since I am using UDP, there is no way to use SSL/TLS, so I have to encrypt each packet alone since the protocol is connectionless/unreliable/unregulated.
Right now, I am using a 128-bit key derived from a passphrase from the user, and AES in CBC mode (PBE using AES-CBC). I decided to use a random salt with the passphrase to derive the 128-bit key (prevent dictionary attack on the passphrase), and of course use IVs (to prevent statistical analysis for packets).
However I am concerned about few things:
Each packet contains small amount of data (like a couple of integer values per packet) which will make the encrypted packets vulnerable to known-plaintext attacks (which will result in making it easier to crack the key). Also, since the encryption key is derived from a passphrase, this will make the key space way smaller (I know the salt will help, but I have to send the salt through the network once and anyone can get it). Given these two things, anyone can sniff and store the sent data, and try to crack the key. Although this process might take some time, once the key is cracked all the stored data will be decrypted, which will be a real problem for my application.
So my question is, what are the best practices for sending/encrypting continuous small data using a connectionless protocol (UDP)?
Is my way the best way to do it? ...flowed? ...Overkill?
Please note that I am not asking for a 100% secure solution, as there is no such thing.
You have several choices. You can use DTLS, which is a version of TLS adapated for datagrams. It is specified in an RFC and implemented in the openssl library. You can also use the IKE/IPsec protocol and use a UDP encapsulation of the IPsec portion. Usually IPsec is available at the OS level. You can also use OpenVPN, which looks to be a hybrid of TLS for key exchange and a proprietary UDP-based packet encryption protocol.
If your problem is that the data is too small, how about extending the data with random bytes? This will make the plaintext much harder to guess.
This question is a little old, but what about using a One Time Pad type approach? You could use a secure reliable transport mechanism (like HTTPS) to transmit the one time keys from the server to your client. There could be two sets of keys -- one for client to sever, and one for server to client. Each datagram would then include a sequence number (used to identify the one time key) and then the encrypted message. Because each key is used for only one datagram, you shouldn't be exposed to the small data problem. That said, I'm not an expert at this stuff, so definitely check this idea out before using it...
Use Ecdh key exchange (use a password to encrypt the client private key; left on the client) instead of a password. This is a very strong key.
Aes cbc does not help you; the messages are too short and you want to prevent replay attacks. Pad your 64 bit message (two integers) with a counter (starting with 0) 64 bits means 2^64 messages can be sent. Encrypt the block twice (aes ecb) and send e(k;m|count)|e(k;e(k;m|count)). Receiver only accepts monotonically increasing counts where the second block is the encryption of the first. These are 32 byte messages that fit fine in a udp packet.
if 2^64 messages is too small; see if your message could be smaller (3 byte integers means the counter can be 80 bits); or go back to step 1 (new private keys for at least one side) once you are close (say 2^64-2^32) to the limit.
You could always generate a fresh pair of IVs and send them alongside the packet.
These days a good streaming cipher is the way to go. ChaCha20 uses AES for a key stream. Block ciphers are the ones that need padding.
Still that's only part of the picture. Don't roll your own crypto. DTLS is probably a mature option. Also consider QUIC which is emerging now for general availability on the web.
Consider using ECIES Stateless Encryption https://cryptopp.com/wiki/Elliptic_Curve_Integrated_Encryption_Scheme where you sending devices use the public key of the central system and an ephemeral key to generate a symmetric key pair, then a KDF, then AES-256-GCM. You end up with modest size packets which are stateless and complete. No need for an out-of-band key agreement protocol.
There are good examples on the internet, for example: https://github.com/insanum/ecies/blob/master/ecies_openssl.c
I am using such a system to deliver telemetry from mobile devices over an unsecure channel.