Security Glossary

A system for exchanging cryptographic keys. Not actually a method for encryption and decryption, but a method of developing and exchanging a shared private key over a public comms channel. Based on discrete-logarithms. Vulnerable to man-in-the-middle attacks. Used in SSH-2.

It is based on two system public numbers p and g known to all users of the system – one is a prime number and the other has a mathematical relationship to it. They may be hard coded or fetched from a server.

The sending end and receiving end independently generate a random secret number s1 and s2. Both then calculate their public key thus: g^s1 mod p (and g^s2 mod p) and send each other their public keys. Both then compute the shared secret key from their own secret key and the other’s public key – both arrive at the same value for the shared secret key.

The algorithm rests on the unfeasibility of calculating the shared secret key given both of the public keys. See http://postdiluvian.org/~seven/diffie.html

Can be used to sign a message or data (e.g. email message or financial transaction) to ensure authenticity. With public key cryptography, the private key is used to create the signature, and users can use the public key to verify the signature.

Digital signatures are usually created from a message digest of the data rather than the data itself.

Sender:

1. Hash the document
2. Sign the hash using the private key
3. Send the plaintext document + signature

Recipient:

1. Calculate the hash independently
2. Decrypt the signature with the public key (retrieving the sender’s hash)
3. Compare sender’s hash with my calculated hash
4. If hashes are the same, signature is valid and the document has not been modified

Also called one-way hash function.

Used to create:

1. a “fingerprint” of a file or a key
2. a digital signature
3. an encryption key from a passphrase.

Generates a seemingly random pattern of bits for a given input.

Finding a different input that produces the same fingerprint is unfeasible (collision-resistant).

Most systems that produce digital signatures encrypt a message digest of the data rather than the data itself.

The fingerprint is a MAC (message authentication code). If combined with a shared secret key it is a HMAC (hash message authentication code) which can be used for many of the same things as digital signatures as an HMAC is faster to calculate and is smaller than a digital signature, but offer comparable signature security; however an HMAC has the disadvantage of being based on a shared key.

A few message digest functions in use: MD2, MD4, MD5, SHA, SHA-1, SHA-256, SHA-384, SHA-512, RIPEMD-160

Symmetric block encryption systems (such as DES) can also be used as message digest functions but are slower.

A user has 2 keys – a public key which can be distributed to other people and which they use to encrypt messages to be sent to the user, and a private (or secret) key which the user uses to decrypt these messages. Only the private key can decrypt these messages and the user must keep it private.

Can also be used for creating digital signatures.

Computationally expensive – typically requires 1000 times more computer power than symmetric key algorithms.

Public key systems in common use are: Diffie-Hellman, DSA/DSS, RSA, Elliptic curves.

Authenticates a user attempting to login from another host.

/etc/rhosts.equiv file is checked first, then the .rhosts file of the local (target) user. Auth stops when a matching positive or negative entry is found.

Two form of entries for granting access to the local system:

1. hostname – all users from the named host may access the system with the SAME username as on the remote host
2. hostname username – in a local user’s .rhosts it means the named remote user may access the system as that local user. In /etc/hosts.equiv it means the named remote user will be allowed access as ANY local user

Better authentication based on AUTH_DES; i.e. authentication data is encrypted but payload is unencrypted so vulnerable to eavesdropping and integrity violation. However see GSSAPI (RPCSEC_GSS ?)

After agreeing a session key, Secure RPC authenticates all RPC requests. Uses a timestamp (with an allowed window) to reduce risk of integrity/replay attacks. But secret key is protected only by weak-ish 56-bit key (AUTH_DES).

Authenticates but does not protect data with encryption or digital signatures (no integrity or confidentiality).

(Needs (?) a server machine – keys are distributed via NIS or NIS+)

RSA authentication (client decrypts challenge from server, returns has to server). 3DES session encryption. Long term server id key, short-term encryption key changes every hour. Can use password authentication. Can tunnel other protocols through SSL connection, e.g. POP, SMTP, IMAP, HTTP, and X. Uses MD5 and SHA-1 for integrity checking. RSAADI who originated MD5 (128 bit) recommend changing to the stronger SHA-1 (160 bit) or RIPEMD-160 (160 bits). Uses zlib for compression.

Servers can be run on any port, so a firewall allowing outgoing connections on a specific port number can be used for a service that was not intended – e.g. for a firewall allowing outgoing connections on port 443 for SSL, an outside SSH server can be set up to monitor connections on port 443 and SSH run locally and told to connect to the remote server on port 443; the user can then tunnel multiple connection types through SSH and the firewall would allow it!

Public key algorithms are RSA (default for Solaris SSH) or DSA. Only one key exchange method – Diffie-Hellman. SSH-2 uses SHA-1 rather than MD5 as its MAC hash function.

End-to-end confidentiality and integrity. Usually authenticates server using a certificate – can authenticate client but never used.

Steps:

1. Negotiate cipher
2. Establish shared session key
3. Authenticate server (optional)
4. Authenticate client (optional – rare)
5. Authenticate previously exchanged data

Uses public key cryptography for authentication, and symmetric encryption for sending data. Uses X.509 certificates.

In server authentication, the client will have a list of certificates from trusted CAs, each one carries the public key of the corresponding CA. The certificate sent from the server is queried for the DN (an X.500 Distinguished Name) of the CA that certified it, and the trusted list of certificates is searched for a certificate with a matching DN. When a match is found among the trusted certificates, the public key is read from the matched certificate and used to verify the CA’s signature on the certificate that was sent from the server. If the verification succeeds it proves that the certificate sent from the server is a valid “letter of introduction” from the CA.

Protects session only. Designed for multiple protocols (e.g. POP3 FTP, SMTP) but only used for HTTP.

Can tunnel via an SSL proxy which is the “end” of the protocol.Can not be proxied (between the ends) because a proxy would be a man-in-the—middle-attack which SSL detects. Uses port 443. OpenSSL library. Needs certificate.

Uses the same key for encryption and decryption, which makes it much faster than asymmetric algorithms. Used for bulk encryption of data or data streams. Two categories: block (encrypts many bytes at a time) and stream (byte-by-byte or bit-by-bit).Sometimes called “secret” or “private” key algorithms (because both parties must keep the key secret) which is confusing as they are not related to public key algorithms. Would need a large number of keys for communication between many people, to prevent a compromised key allowing an attacker to decrypt traffic between all users.

Some common symmetric algorithms are: Blowfish, DES, IDEA, MARS, RC2, RC4, RC5, RC6, Rijndael, Serpent, Triple-DES (3DES), Twofish, AES. Best rated are RC2 and Rijndael.