I'm learning the asymmetric encryption and key exchange process, so I followed this process described here. Generally I understand how it works and the purpose, but I'm still not clear on three things: 1. It's probably doesn't matter because of encryption, but what decide the hash algorithm used for digital signature? In case of CA server, its probably what you choose when you install CA role, but in case of client? For example a client access https website, or send certificate request to a CA. 2. In case of digital envelopes, when secure data transmission used, SSL for example, is the data always encrypted with asymmetric public key of the receiver, or just the symmetric session key exchanged first, and then its using symmetric encryption (key encapsulation)? I guess it depends on protocol, because EFS using encapsulation, and SSL probably too. since you can transfer lots of data with https. 3. In case of EFS, key encapsulation used: User activate encryption on a file, its encrypted with symmetric key, and symmetric key encrypted with asymmetric public key of the user. So now only that user, with a private key, have access. What about when DRA or additional user added to authorization list? Do they use their private keys or public for encapsulation? It make no sense to me to use private key, but I just have an article here that says they use private keys. Probably some mistake.

1. The hash algorithm in both cases (CA, and cert request) is configurable. There will be a default, but you can override it. These days you should future-proof your system by choosing SHA256. Up till recently SHA-1 was normal, but it's starting to look shaky. 2. The data is never encrypted under the public key directly, any of the scenarios you describe. Nor in any related scenarios. It is always encrypted in two stages as you say: encrypt the data under a symmetric key, and encrypt the symmetric key under the public key. 3. Same for DRA. For every authorized user, her public key is used to encapsulate the symmetric key. Your intuition is correct. If the article really said that, it is wrong. If you want to post the url and page number here I will explain where it is wrong (wow, talk about going the extra distance!). Mike

So is it possible for example to capture the key exchange traffic, decrypt the hash with a public key, then check the hash against at rainbow table to get a session key, and then decrypt the rest of the data, right? Theoretically... if its some dumb protocol that uses under 8 characters session key with 160 bits or less hashing.

Gregsm, this is confused and hard to respond to. During the SSL handshake, some bytes are sent back and forth, some of which are encrypted under a public key. Your attacker cannot decrypt anything encrypted under a public key. Only the private key can decrypt that. This point is the fundamental thing that makes SSL work. Mike

I'm learning the asymmetric encryption and key exchange process, so I followed this process described here. Generally I understand how it works and the purpose, but I'm still not clear on three things: 1. It's probably doesn't matter because of encryption, but what decide the hash algorithm used for digital signature? In case of CA server, its probably what you choose when you install CA role, but in case of client? For example a client access https website, or send certificate request to a CA. 2. In case of digital envelopes, when secure data transmission used, SSL for example, is the data always encrypted with asymmetric public key of the receiver, or just the symmetric session key exchanged first, and then its using symmetric encryption (key encapsulation)? I guess it depends on protocol, because EFS using encapsulation, and SSL probably too. since you can transfer lots of data with https. 3. In case of EFS, key encapsulation used: User activate encryption on a file, its encrypted with symmetric key, and symmetric key encrypted with asymmetric public key of the user. So now only that user, with a private key, have access. What about when DRA or additional user added to authorization list? Do they use their private keys or public for encapsulation? It make no sense to me to use private key, but I just have an article here that says they use private keys. Probably some mistake. EFS payload (actual data) is encrypted by using symmetric key. In the DRA field this symmetric key is encrypted by owner/recovery agent public key. If someone is added to the EFS access its public key is used to encrypt symmetric encryption key. Since all key encryption operations uses public keys it is not possible to compromise symmetric key without having corresponding private key.My weblog: http://en-us.sysadmins.lv PowerShell PKI Module: http://pspki.codeplex.com Windows PKI reference: on TechNet wiki

Yes yes, mike already wrote that :)