Sidenote, when dealing with passwords and
hashes it is not such a big deal if the hash is not collision-resistant — a
real pain would be the possibility to construct a preimage.
Password-Based Key Derivation Function (PBKDF2)
key-derivation function based on iteratively deriving HMAC with some padding.
the reason for such constructions is to slow down any attacker if DB was compromised.
The password going to PRF might be too long if the user is paranoid enough,
so it is necessary to shorten it with some hash function.
This leads to a possibility of having multiple passwords with the same
PBKDF2 but it shouldn’t be a huge deal.
Used in Django by default.
Argon2
PBKDF is prone to GPU and ASIC attacks so people wanted something better.
From Password Hashing Competition (2013)
From the University of Luxembourg.
Rather complex.
3 parameters:
A time cost, which defines the amount of computation realized and
therefore the execution time, given in number of iterations
A memory cost, which defines the memory usage, given in kibibytes
A parallelism degree, which defines the number of parallel threads
Ticket Granting Service (TGS) has a shared secret
key with each principal.
Anytime some two principals want to communicate with each other
they ask TGS to generate a key for them.
Let’s say A wants to communicate with B.
TGS generates KAB and sends Alice KAB,EKB−TGS(KAB)
both encrypted by A’s key.
A can then send B the session key that only B can decipher.
This all seems simple but its implementation is hard
and there are many subtle problems in it.
It is recommended to use the official Kerberos
and not try to code something own.
Clients can use passwords to access TGS.
To prevent offline attacks we use preauthentication .
Eh(passwd)(timestamp)
We remember packets from the time window because
clocks might not be synchronized.
We need to prevent reply attacks.
DNSSEC (Secure Domain Name System)
We can see a DNS as a tree of domain names, in each vertex,
there are multiple records (like A, AAAA, MX).
The tree is used to define relationships between domains and their subdomains.
Each zone has a DNSKEY, with this we can sign some records
and verify signatures of RRSIG.
A zone can be signed offline and then we only serve RRSIGs.
We can even sign holes when there is a nonexistent record.
Allows for two useful things:
Data origin authentication
Data integrity protection
Verifying identity
Directory services
Maps names of network resources to their network addresses.
Must be always online to provide information.
LDAP for example.
Can be used inside an organization (smaller scale than the whole Internet).
We can see it as a lookup table but such a view is a
big simplification because not all devices in the network are equal.
Everybody has the public key of DS.
Offline protocol for registering keys.
Certification authorities
A better version of DS where it is not needed for DS to be online all the time.
Have keys and sign other parts of the net.
When they are down it is not possible to sign
a new record but it won’t shut down the web.
Critical for the public key infrastructure.
They provide trust.
Often they sign also other CAs so it can seem that some CAs are more important than others.
When Bob connect to Alice, she sends him her key with
a certificate from CA certifying that the key really belongs to Alice.
Everybody in the world needs to trust the top-level CAs which is impossible.
And we have the Public Key Infrastructure!
Web of trust
Sadly not working but a nice idea.
Used in PGP.
Phil Zimmermann.
Directed graph.
Trust on first use (TOFU)
Assumes no attacker is present in the initial connection.
The first connection establishes a trust usually
approved by the user.
In all subsequent connections the second party is trusted.
