Cryptography - My notes and links

• Forward Secrecy is a feature of specific key-agreement protocols that gives assurances that session keys will not be compromised even if long-term secrets used in the session key exchange are compromised.
• for HTTPS, the long-term secret is typically the private key of the server
• Forward Secrecy protects past sessions against future compromises of keys or passwords
• by generating a unique session key for every session a user initiates, the compromise of a single session key will not affect any data other than that exchanged in the specific session protected by that particular key
  • this by itself is not sufficient for Forward Secrecy which additionally requires that a long-term secret compromise does not affect the security of past session keys
• if Forward Secrecy is used, encrypted communications and sessions recorded in the past cannot be retrieved and decrypted should long-term secret keys or passwords be compromised in the future, even if the adversary actively interfered, for example via a MiTM attack
• Forward Secrecy protects past communication
  • this reduces the motivation for attackers to compromise keys
  • for instance, if an attacker learns a long-term key
    • but the compromise is detected
    • and the long-term key is revoked and updated
    relatively little information is leaked in a forward secure system
• Forward Secrecy typically uses an ephemeral Diffie–Hellman key exchange to prevent reading past traffic.
  • The ephemeral Diffie–Hellman key exchange is often signed by the server using a static signing key.
  • If an adversary can steal (or obtain through a court order) this static (long term) signing key, the adversary can masquerade
    • as the server to the client
    • and as the client to the server
    and implement a classic man-in-the-middle attack.

The value of Forward Secrecy depends on the assumed capabilities of an adversary :

The value of Forward Secrecy is limited :

1. Alice and Bob each generate a pair of long-term, asymmetric public and private keys
   1. then verify public-key fingerprints in person or over an already-authenticated channel.
   2. Verification establishes with confidence that the claimed owner of a public key is the actual owner.
2. Alice and Bob use a key exchange algorithm such as Diffie-Hellman, to securely agree on an ephemeral session key.
   1. They use the keys from step 1 only to authenticate one another during this process.
3. Alice sends Bob a message, encrypting it with a symmetric cipher using the session key negotiated in step 2.
4. Bob decrypts Alice's message using the key negotiated in step 2.
5. The process repeats for each new message sent :
   1. starting from step 2
   2. and switching Alice and Bob's roles as sender/receiver as appropriate
   3. step 1 is never repeated

if I get it right :
* the long-term secrets are used to authenticate each other ("//you are the one you pretend to be//") while negotiating the **session key** at step 2
* since a new session key is generated for each message :
	* if a session key is leaked, it can be used to disclose a single message only
	* no past nor future message can be read using this key
* if Alice's long-term private key from step 1 is compromised :
	* someone can masquerade as Alice (or eavesdrop) during step 2, which means :
		* this person has access to all future session keys
		* all future messages are compromised

• several cryptanalytic attacks become easier the more material encrypted with a specific key is available
  by limiting the amount of data processed using a particular key, those attacks are rendered harder to perform
• asymmetric encryption is too slow for many purposes, and all secret key algorithms (aka symmetric algorithms) require that the key is securely distributed
  by using an asymmetric algorithm to encrypt the secret key for another, faster, symmetric algorithm, it's possible to improve overall performance considerably