CRYPTOGRAPHY
1
2
Ref. & doc................................................................................................................................................................... 1
Symmetric, asymmetric (PKE) ................................................................................................................................... 1
2.1.1
Symmetric ................................................................................................................................................... 1
2.1.2
Asymmetric (Public Key Encryption) ........................................................................................................ 1
2.1.3
Symmetric vs asymmetric ........................................................................................................................... 2
3 Certification, digital signature .................................................................................................................................... 2
3.1
Certificate ........................................................................................................................................................... 2
3.2
Digital signature.................................................................................................................................................. 2
4 SSL (TLS)................................................................................................................................................................... 3
4.1
General................................................................................................................................................................ 3
4.2
Protocol ............................................................................................................................................................... 3
4.3
Details, more ....................................................................................................................................................... 3
4.3.1
SSL without certificate ?............................................................................................................................. 4
4.4
HTTPS ................................................................................................................................................................ 4
5 Kerberos...................................................................................................................................................................... 4
Written and/or compiled from other sources by François Hill
2013.05.05 First version
This memo is by no means an exhaustive documentation on the subject matter. It is meant as a dynamic support
document primarily for the use of the author and as such addresses his needs and concerns first and foremost. This is not
a tutorial! (fundamental points may well be omitted)
The author cannot be held responsible for any use which may be made of the information contained therein. Use at own
discretion.
While a lot of the present material is readily available in different documentations, the main effort of the author has been
in compiling, recouping and highlighting the most used elements, do’s and don’ts, pitfalls etc. – reflecting mostly his
own precise needs.
1
Ref. & doc.
 [ref name] = http://ref_address.com
2
Symmetric, asymmetric (PKE)
2.1.1 Symmetric
Symmetric-key algorithms[1] are a class of algorithms for cryptography that use the same cryptographic keys for both
encryption of plaintext and decryption of ciphertext. The keys may be identical or there may be a simple transformation to
go between the two keys. The keys, in practice, represent a shared secret
http://en.wikipedia.org/wiki/Symmetric-key_algorithm
Examples: Twofish, Serpent, AES (Rijndael), Blowfish, CAST5, RC4, 3DES, and IDEA

Fixed size overhead even when encrypting gigabytes of data.
2.1.2 Asymmetric (Public Key Encryption)
 Pair of linked keys: public & private
 Public key = encrypt Private = decrypt
 Based on mathematical "asymmetric" relationships where doing and undoing are not performed in the same way,
and undoing (without the private key) is very complicated.





o Real-life analogy : breaking a seal, jumbling a Rubik's cube …
Anybody to whom the public key is known can encode a message
Only the holder of the private key can decrypt message
Security lies within the secrecy of the private key
Sender and receiver must agree on the algorithm used
Examples of algorithms: Diffie Helmann, RSA
2.1.3 Symmetric vs asymmetric
Col 1
Symmetric
Asymmetric
Speed
Strength
faster
slower ("a lot")
weaker for same key bit length (=> larger key
Overhead
Secret
fixed
Shared: keys must be exchanged/sent
which is problematic if not face to face
for equivalent protection which contributes
to above)
Proportional (e.g. at least +10% for RSA)
Only public key is shared.
http://security.stackexchange.com/questions/3657/symmetric-encryption-session-keys-in-ssl-tls
3
Certification, digital signature
3.1 Certificate
 A certificate identifies somebody through a trusted 3rd party.
 Relies on PK encryption
[FHI - this is what I gather]
1. Merchant site amazon (for example) requests a certificate from trusted 3rd party and sends them their public
key.
2. Trusted 3rd party encrypts a message, e.g. "We have verified that amazon, merchant id xxx, address xxxx, has
the following public key: xxxxx", with its own private key (and an encryption protocol). This message is the
certificate. It binds id info with a public key. 3rd party delivers certificate back to merchant.
3. A client wants to initiate a transaction with amazon (or somebody stating they are).
4. Amazon sends the certificate to the client
5. Client connects to trusted 3rd party, gets their public key, decrypts certificate.
6. Client now is sure that key xxxxx is that of amazon.com. (although he's still not sure it is really amazon. If it's
not, in any case the spoofer will not be able to read the encrypted transaction since they don't have the private
key to decrypt. To be sure it is indeed amazon, a digital signature mechanism would be needed)
 In effect, the certificate content (merchant id, merchant PK) is digitally signed (see that section) by the 3rd party.
 The reliance on something external to the system (3rd party, assumption) is the "keystone" of PK certification
scheme.
 Browsers have built-in lists of trusted 3rd parties (see also "root certificates"). They can be added/deleted.
3.2 Digital signature
 cryptographically binds an electronic identity to an electronic document:
=> guarantees authenticity (id of sender)
 also guarantees integrity
 cannot be copied to another document.
[FHI - this is what I gather]
1. Alice wants to send Bob a message
2. Alice computes a print of the message (e.g. md5)
3. Alice encrypts the print with her private key (message need not)
4. Alice sends the message along with the encrypted print of the message
5. Bob uses Alice's public key to decrypt the print
6. Bob computes print of received message and compares it to received print: they should match.
7. If Bob is sure (see certificate) who's public key he used in step 5, then he is sure that
a. it was indeed Alice who sent the message (the sole owner of the private key associated to the public
key)
b. the message hasn't been tampered with (integrity)
4
SSL (TLS)
http://security.stackexchange.com/questions/20803/how-does-ssl-work
http://research.zscaler.com/2008/10/ssl-encryption-without-authentication.html
http://www.commentcamarche.net/contents/215-cryptographie-secure-sockets-layers-ssl
4.1 General





SSL is now "TLS"
Operates over TCP (level 4, transport) (needs guarantee of delivery)
and under the application layer (level 7: HTTP, FTP …)
Independent from the application protocol: can be used with any
When used correctly, all a on onlooker sees is IP @, approx. size of data, encryption & compression used and a
few other things (server name, full server certificate…)
4.2 Protocol
 Client connects to SSL-secured server, asks him to authenticate himself. Client sends info on protocol specifications
it supports
 Server sends certificate (contains the server's public key)
 Client verifies certificate (possibly via 3rd party)
 Client creates (pseudo-)random private key, encrypts it with the server's public key, sends it over to the server. This
is the session key
 Server decrypts private key sent by client. Now both have a shared, private key. (and symmetric encryption is used
thereafter).
4.3 Details, more
Technically SSL/TLS does not need certificates to secure a communications channel. In fact it SSL/TLS can use other
mechanism to secure the channel: pgp certs, username/password, pre-shared keys, or "anonymous" (no
authentication at all). Similarly SSL/TLS does not guarantee encryption, there are many different cyphers it can use,
including "null" (no encryption at all). And there are similar options for digest authentication. So that's all great, but what
programs use any of it: basically none at all, definitely no major server or browser software (they all require certificates)
http://serverfault.com/questions/343442/can-https-work-without-a-certificate
What if an attacker intercepts the encrypted login request, can't he used that encrypted request to impersonate the
legitimate client? or manages to pinpoint the location of the encrypted password and use it ?
It seems a well configured SSL connection 'rotates' the encryption scheme: no 2 successive encryptions of the same
content should yield the same encrypted content. I guess the 'rotation' info is decided durig the handshake.
Using a multisession version of Vaudenay's CBC-PAD attack [10], it is possible to attack TLS/SSL in the case when the
message that is being encrypted remains the same during each session.
http://lasec.epfl.ch/memo/memo_ssl.shtml
Does SSL protect users from replay attack by eavesdroppers or message interceptors?
Yes. The client and the server each provide part of the random data used to generate the keys for a connection. (The random
portions of the connection that initiate a session, drawn from both the client and the server, are used to generate the master
secret associated with that session.) Additionally, each record is protected with a MAC (Message Authentication Code) that
contains a sequence number for the message.
http://stason.org/TULARC/security/ssl-talk/4-1-Does-SSL-protect-users-from-replay-attack-byeavesdropp.html#.UYfIuVKe3SU#ixzz2SWfJghVj
4.3.1 SSL without certificate ?
 It seems, YES.
 Either with a "self-signed" certificate (however beware of limitations, see links)
 Either using anonymous mode (however, "useless to prevent against man in the middle")
 Either by using SSL with a pre-shared keys (TLS-PSK)
 Other: see excerpt
HTTPS is HTTP over SSL/TLS, and you can use SSL/TLS without certificate or with certificates of other types than X.509.
- Anonymous cipher suites: they can provide encryption, but without authentication. Rather useless as far as security is
concerned... To quote RFC 4346: "anonymous Diffie-Hellman is strongly discouraged because it cannot prevent man-inthe-middle attacks."
- Pre-shared keys: it has its own mechanism to verify the remote identity, but the shared nature of the keys brings its own
set of problems (in particular limited deployment).
- Kerberos cipher suites: the client can verify the identity of the server against the Kerberos principal name.
http://serverfault.com/questions/343442/can-https-work-without-a-certificate
Ibid.
 Other resources:
http://research.zscaler.com/2008/10/ssl-encryption-without-authentication.html
4.4 HTTPS
Web browsers know how to trust HTTPS websites based on certificate authorities that come pre-installed in their
software. Certificate authorities (e.g. VeriSign/Microsoft/etc.) are in this way being trusted by web browser creators to
provide valid certificates. Logically, it follows that a user should trust an HTTPS connection to a website if and only if all of
the following are true:
The user trusts that the browser software correctly implements HTTPS with correctly pre-installed certificate authorities.
- The user trusts the certificate authority to vouch only for legitimate websites.
- The website provides a valid certificate, which means it was signed by a trusted authority.
- The certificate correctly identifies the website (e.g., when the browser visits "https://example.com", the received certificate
is properly for "Example Inc." and not some other entity).
- Either the intervening hops on the Internet are trustworthy, or the user trusts that the protocol's encryption layer (TLS/SSL)
is sufficiently secure against eavesdroppers.
[Wikipedia]
5
Kerberos
 Computer network authentication protocol
 Lets 2 parties prove their identity to one another (mutual identity trust) in a secure manner over a non-secure
network
 Uses a trusted 3rd party (via a secret: e.g. password)
 Uses SKE (symmetric key encryption)
 Only optionally requires PKE during certain phases of authentication
 At the end of the authentication, both parties have a secure connection to each other [FHI so I gather]
 Used primarily over networks (Windows, Unix)
After Kerberos authentication, it is established that:
- Client believes Server is who it intended to contact
- S believes C is who it claims to be
- C believes that it has a secure connection to S
- C believes that S believes it has a secure connection to C
- S believes that it has a secure connection to C
- S believes that C believes it has a secure connection to S
[http://stackoverflow.com/questions/111386/difference-between-ssl-and-kerberos-authentication ]