Calculations are fast
Arbitrary numbers can be used as key (usually)
If the system itself has no weakness and is properly used:
64 bit keys are insecure (“brute force”: simply try all possible keys using many computers)
128 bit keys are secure against attacks with classical computers (for physical reasons)
Each bit more doubles the security: 2¹²⁹ = 2 × 2¹²⁸
256 bit keys are secure against attacks with quantum computers
Each two bits more double the security against quantum computers: √2²⁵⁸ = 2 × √2²⁵⁶
Examples
Secret writings, DES, RC5, IDEA, CAST, Blowfish, Twofish, Rijndael (AES), ChaCha20
Asymmetric Cryptography (public key systems)
Uses two complementary keys (key pairs)
One key for encrypting, the other for decrypting
One key for signing, the other for verifying
From one key the other key cannot be calculated
⇒ One key can be public
Only one key pair per participant
One key (the private key) is used by the owner of the key pair
The other key (the public key) is used by all other participants
With n participants, you need only n key pairs
The number of keys increases only linearly with the number of participants
Public key systems: When which key?
Use the private key for those actions that only the owner may do
Signing (by sender) and verifying (by any recipient or third party):
Only the sender may sign
⇒ private key of sender for signing
⇒ corresponding public key of sender for verifying
Encrypting (by any sender) and decrypting (by recipient):
Only the recipient may decrypt
⇒ private key of recipient for decrypting
⇒ corresponding public key of recipient for encrypting
How do public key systems help?
Encrypting prevents meddlers from reading
Verifying the signature proves the originating sender
Verifying the signature proves that the message is unaltered
Everybody can verify the signature
Encrypting and signing are independent of each other
Need only signing? ⇒ only the sender needs a key pair
Need only encrypting? ⇒ only the recipient needs a key pair
Public keys can easily be distributed
New danger: How do we know that a public key is genuine?
Properties of public key systems
Only numbers with certain properties can be used as keys
Systems are based on various mathematical issues, mostly on:
Huge prime numbers
Examples: RSA, ElGamal/DH, Rabin, ...
Elliptic curves (ECC)
Examples: NIST Curve P‑192 ... P‑521, Curve25519, Curve448, E‑521, Brainpool P256t1, ...
Calculations are slower (by a factor of 1000) due to huge numbers
Too slow for huge amounts of data
Combine secret key system + public key system + fingerprints + randomness to speed up
| Secret key DES/AES/... | Public key RSA | Public key ECC | Keys are currently considered |
|---|---|---|---|
| 56/64 (1997/2002) | 829 (2020) | 109 (2004) | broken (year) |
| 80 | 1024 | 160 | weak |
| 120 | 2800 | 240 | sufficient |
| 128 | 3072 | 256 | “classic” secure |
| 256 | – | – | “quantum” secure |
Key sizes and security
Larger keys are usually more secure
Very different absolute numbers depending on algorithm for same estimated security → table
But: In 1–2 decades, quantum computers will be able to break within hours:
all currently used public key systems
some currently used secret key systems
“Post-quantum” systems are being developed
Regarding security, key size is only one factor
(usually far from being the weakest link in the chain)
Cryptographic essences (fingerprints)
Mathematical hash function, one-way function
Calculations are fast
Create from message of arbitrary length an essence (fingerprint) of fixed length
Essences are very short, 128 to 512 bit (16 to 64 byte)
Cryptographic requirement: From an essence the message cannot be calculated
More drastic requirement: No two different messages with the same essence can be found
Birthday paradoxon: Security is only half the length
256 bit hashes have the security of 128 bit symmetric keys
Then signing the essence is as good as signing the message
Examples: MD5 (128 Bit, broken), SHA‑1 (160 Bit, broken), RIPEMD‑160 (160 Bit, weak), SHA‑2 (256 to 512 Bit), BLAKE2 (224 to 512 Bit), SHA‑3 (Keccak, 224 to 512 Bit), ...
Part 3: Combine cryptographic building blocks for speed
Sign
Fast: Calculate essence of message
Slow but few data: Encrypt essence with sender's private key
The signature is the encrypted essence
Transmit message and signature to the recipient
(This signature method is used most often but there are other methods.)
Verify
Slow but few data: Decrypt signature with sender's public key
Fast: Calculate essence of message
Fast and few data: Compare the results of both steps
If they are not equal, then message or signature are not genuine
Sign and Verify
Encrypt
Create random key for secret key system
Creating good random numbers is a really hard task for deterministic computers
Fast: Encrypt the message (with signature) with random secret key
Slow but few data: Encrypt the random secret key with recipient's public keys
(Multiple recipients? Do this for every recipent)
Transmit encrypted message and encrypted random key(s) to recipient(s)
Decrypt
(Multiple recipients? Pick the encrypted random secret key that is encrypted with your public key)
Slow but few data: Decrypt the encrypted random secret key with the recipient's private key
Fast: Decrypt the (signed) message with the random key
Names like TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 describe the algorithms combined
Encypt and Decrypt
Summary
Sender
signs with sender's private (secret) key
encrypts with recipient's public key
Recipient
decrypts with recipient's private (secret) key
verifies with sender's public key
Always remember:
You need your private key only for signing and decrypting, never else
Don't worry – your software makes all the rest for you
Part 4: Certificates and Certification Authorities
How do I get somebody's public key?
Danger: How do we know that a public key is genuine?
Often not feasible: Personal handover or trustworthy courier
Split the problem:
Transfer the public key (may be insecure)
Check the authenticity of the received key
How to transfer:
Email, WWW, LDAP, Keyserver, etc.
S/MIME signatures contain the public key, most email programs remember them
How to check the authenticity:
Check the fingerprint obtained from a trustworthy source
Check the signature of the message containing the key (If sender = owner: The cat catches its tail?)
Check the certificate containing the key
Certificates
Certificates are electronically signed confirmations
“This public key belongs to this identity (person, server)”
Fixed formats (OpenPGP, X.509, OpenSSH, ...) for automatic verification
Contents of a certificate
Certificates contain:
Public Key (X.509) or its fingerprint (OpenPGP)
Owner of key (“subject”: full name or FQDN, organization etc.)
X.509: “E=rainer.perske@uni-muenster.de, CN=Rainer Perske, GN=Rainer, SN=Perske, O=Universität Münster, ST=Nordrhein-Westfalen, C=DE”
X.509: “CN=www.uni-muenster.de, O=.....” (see above)
OpenPGP: “Rainer Perske (office) <rainer.perske@uni-muenster.de>”
Further data (issuer, serial number, validity period, purpose, alternative names like email addresses)
Signature created by issuer
Certificates do not contain the owner's private key!
When to use a certificate
You present your certificate:
As a person/group: when sending a signed email (attached to the signature)
The recipient will check signature and certificate
As a server: when accepting an TLS (HTTPS, IMAPS, POP3S, ...) connection
The client will check the certificate and compare the host name
As a client: when connecting to an TLS (HTTPS, IMAPS, POP3S, ...) server
Only if expected by the server (better security than password authentification)
The server will check the certificate
Try: https://xsso.uni-muenster.de/IT-Portal/
As a programmer: when signing a piece of software code
The operating system of the target system will check signature and certificate before installing
As an author: when signing a document (e.g. PDF)
The document reader software will check the certificate (if capable)
How to check certificates
Non-technical:
Is the issuer trustworthy?
Is the issuer competent?
This assessment should be done by the person to whom the certificate is presented
However, most people simply use the trust settings supplied by the software manufacturer
Technical:
Verify the authenticity of the certificate
Either compare with a fingerprint obtained from a trustworthy source
Or check its signature with the issuer's public key
(The cat catches its tail? No, it catches the tail of the preceding cat)
Certification chains / hierarchies
A certificate is signed with a public key
which is contained in another certificate
which is signed with a public key
which is contained in yet another certificate
... ... ...
The final certificate is signed with itself: root certificate
user or server certificate ← intermediate certificate ← ... ← intermediate certificate ← root certificate ⮌
How to check a certification chain
A certificate is valid, if
the root certificate is genuine and
all issuers in the chain are trustworthy and competent
When you present your certificate, you have to present the intermediate certificates, too
Then the certificate checker only needs the root certificate
Software vendors include many pre-checked root certificates
Demo: List root certificates in Firefox – and edit trust
Demo: Check certificate of this page (server) or of a user
www.uni-muenster.de ← Sectigo RSA ... Server CA ← USERTrust RSA Certification Authority ⮌
More information about DFN-PKI + GÉANT TCS + Sectigo + USERTrust Network in next part
How to become a root CA
A certification authority (CA) is somebody issuing certificates as his business
With OpenSSL: https://www.openssl.org
Set up a complete root CA:
mkdir demoCA demoCA/newcerts ; touch demoCA/index.txt ; echo 01 >demoCA/serial
openssl req -x509 -newkey rsa:4096 -out CA.crt -keyout CA.keyPublish CA.crt
By client: create a key pair and a request:
openssl req -new -nodes -out XY.req -keyout XY.keyBy CA: issue certificate:
openssl ca -days 10 -keyfile CA.key -cert CA.crt -in XY.req -out XY.crt
CAs and root CAs are not “per se” trustworthy
How to become a serious root CA
Set up a policy with rules for security, target audience, privacy, methods, archiving, contents, life times, revocations etc. you declare to obey strictly
Announce yourself to the browser makers (for Mozilla use Bugzilla)
Example: Deutsche Telekom Root CA 2: https://bugzilla.mozilla.org/show_bug.cgi?id=378882
Request sent: April 2007; integration in Firefox+Thunderbird: July 2009
Rigorous checking of requirements (policies, audits etc.) over months and years
Requesting CA has to adapt every little bit of its policy and its operation to the requirements
Leading party in the ongoing development is the CA/Browser Forum: https://cabforum.org/
Most of our policy changes in the last years came due to new CA/Browser Forum requirements
It costs millions of Euros to operate a CA that meets all requirements:
All universities delegate CA operation via DFN and GÉANT TCS to (currently) Sectigo
We don't want to trust “Honest Achmed”: https://bugzilla.mozilla.org/show_bug.cgi?id=647959
Serious background: blunders of Commodo, DigiNotaar etc.; activities of Iran, Kazakhstan, China etc.
