tags : Security, PKI, TLS, Encryption, Hashing
FAQ
What is a construction?
- A way of combining basic building blocks, such as encryption algorithms, hash functions, and protocols, to create a higher-level cryptographic scheme or system.
- Examples
PRF?
pseudorandom function
AEAD?
- AEAD stands for “Authenticated Encryption with Associated Data.”
- Why I have settled on XChaCha20+Blake3 as the AE suite of choice for my proje…
TODO Modes??? (ChatGPT generated)
block
-
Electronic Codebook (ECB):
- Each block of plaintext is independently encrypted with the same key.
- Identical plaintext blocks result in identical ciphertext blocks.
-
Cipher Block Chaining (CBC):
- Each plaintext block is XORed with the previous ciphertext block before encryption.
- Initialization Vector (IV) is used for the first block to break patterns.
-
Cipher Feedback (CFB):
- Turns a block cipher into a stream cipher.
- Previous ciphertext block is fed back into the block cipher to generate a keystream.
-
Output Feedback (OFB):
- Similar to CFB but the block cipher encrypts a constant value (IV) to produce a keystream.
- The keystream is then XORed with the plaintext.
-
Counter (CTR):
- Turns a block cipher into a stream cipher.
- Uses a counter as the input to the block cipher to generate a keystream.
- The counter is usually combined with a nonce.
-
Galois/Counter Mode (GCM):
- Combines the counter mode of operation with Galois field multiplication.
- Provides both confidentiality and authenticity.
- Widely used for authenticated encryption.
Stream Cipher Modes:
- Synchronous Stream Ciphers:
- Keyed bits are generated to form a pseudorandom keystream.
- The keystream is then XORed with the plaintext to produce the ciphertext.
- Self-Synchronizing Stream Ciphers:
- Previous ciphertext bits are used to generate the next key bits.
- Allows synchronization even if some ciphertext bits are lost or corrupted.
- Stream Cipher with Feedback (SCFB):
- Similar to CFB mode for block ciphers.
- Uses the previous ciphertext bits to generate the next keystream.
- Combining Generators:
- Multiple keystream generators are combined to improve security.
- Filter Generators:
- Combines a linear feedback shift register (LFSR) with a nonlinear filter.
Passwords
- PAKE
Encrypt passwords?
- Storing passwords HMAC encrypted is technique outdated by at least 10 years
SCRAM
The beauty of SCRAM is that both authenticating parties (in this case, your client/application and PostgreSQL) can both verify that each party knows a secret without ever exchanging the secret. In this case, the secret is a PostgreSQL password!
- How to SCRAM in Postgres with pgBouncer | Crunchy Data Blog
- Get Your Insecure PostgreSQL Passwords to SCRAM | PPT
- https://datatracker.ietf.org/doc/html/rfc5802
Basics
- The basis of SCRAM is that both a client and a server
- will send each other a series of
cryptographic proofs
demonstrating that they know the secret (i.e. the password). - Needed keys
- “Client Key”
- “Server Key” (Server needs to know)
- “Stored Key” (Server needs to know)
- will send each other a series of
-
Client key
-
Stored key (Derived from Client key)
-
Server key
Flow
You connect to you PG server using normal username and pass only, all this mumbo/jumbo is what your postgrest client library will handle. SCRAM is well supported.
-
Client
Sends the server a
"client proof"
client proof = client key XOR client signature
client signature = HMAC(one-time info of signing key) + stored key
stored key = sha256(client key)
-
Server
Derives the
client key
fromclient proof
and verifies if it OK by taking aSHA-256(client key)
and comparing it againststored key
i.e Server uses the
stored key
for two different usecases- Since server has
stored key
, and it only sends the one time info- It can generate the
client signature
- It can generate the
- So once it gets the
client proof
from a client,client key = client_signature XOR client_proof
- Since server has
-
Flow when we’re using PGBouncer
- How to SCRAM in Postgres with pgBouncer | Crunchy Data Blog
- The above nicely describes how 2 parties are talking, when we have a 3rd party(pgbouncer) things get a little bit different
client key = salt(password)
, wheresalt
is sent by the server at initial requeststored key = sha256(client key)
- Flow
- In this flow, we’re trusting the pgbouncer instance.
- client sends
client proof
to pgbouncer - pgbouncer extracts the
client key
just liek pg would - pgbouncer now generates a new
client proof
where pgbouncer is now the actual client and sends the newclient proof
to pg
Comparison with md5(See Hashing) for PostgreSQL
'md5' || md5(password + username)
- If you have access to someone’s
- username / password combination
- or their PostgreSQL MD5-styled hash
- You could log into any PostgreSQL cluster where the user has the same username / password.
- The md5 has a challenge/response thing but the password itself is not salted!
-
Attacks
Replay attacks
: These are prevented by md5 because there is a challenge/response component, so the md5 hash which is stored is not what is sent across the wire.- But someone with enough skills can still try figuring things out.
Gaining dump of the at-rest-hash
: If an attacker somehow gains access to the at-rest-hash, then they can figure out the actual password.- Using something like SCRAM prevents this.
Cipher
See Cipher
Other topics
Forward secrecy
- If you lose your key to an attacker today
- They still can’t go back and read yesterday’s messages
- They had to be there with the key yesterday to read them
- Layman implementation
- 2 secret keys: a short term session key and a longer-term trusted key.
- The session key is ephemeral (usually the product of a DH exchange)
- The trusted key signs the session key.
- See Forward Secrecy {The Call of the Open Sidewalk}
Things I keep hearing about
- AES-CTR, HMAC-SHA2
- XChaPoly
- XChaCha
- Blake
- Macaroons
- Biscuit