Tiny Bytes: RSA
tldr RSA works by exploiting the fact we can’t easily factor 2 large prime numbers and group theory to make a trapdoor permutation, aka a function that turns x into y but y can’t easily be turned into x without a secret. However, implementing RSA gets tricky because there’s lots of subtle attacks.MathRSA takes advantage of the group Z^*_{n} (multiplicative group of integers modulo n). This is the non-negative integers less than n that have an inverse modulo n. 1 x 1 mod n = 1. 0 x int = 0 so ...
Tiny Bytes: Chilling
Hi, Just chilling tonight. Aiming to finish up chapter tomorrow. Night, Lucas
Tiny Bytes: Quickie
Hi, Did much more writing on RSA. Will finish soon. Bye, Lucas
Tiny Bytes: RSA
tldr RSA works by exploiting the fact we can’t easily factor 2 large prime numbers and group theory to make a trapdoor permutation, aka a function that turns x into y but y can’t easily be turned into x without a secret. However, implementing RSA gets tricky because there’s lots of subtle attacks.MathRSA takes advantage of the group Z^*_{n} (multiplicative group of integers modulo n). This is the non-negative integers less than n that have an inverse modulo n. 1 x 1 mod n = 1. 0 x int = 0 so ...
Tiny Bytes: Chilling
Hi, Just chilling tonight. Aiming to finish up chapter tomorrow. Night, Lucas
Tiny Bytes: Quickie
Hi, Did much more writing on RSA. Will finish soon. Bye, Lucas
Subscribe to ldnovak
Subscribe to ldnovak
<100 subscribers
<100 subscribers
Share Dialog
Share Dialog
Hi,
One bit I wanted to follow up is with an interesting HMAC issue. If the key used for HMAC is longer than the block size of the underlying hash function than a hash(key) is used instead.
This technically creates a collision: I have 2 keys, k and H(k), that create the same MAC. Therefore, I have a way to generate valid MACs for k without knowing what k is.
From my understanding, this decreases the security of HMACs using keys larger than block size, but in many scenarios not meaningfully so. If SHA256 is used, the number of bytes of security is min(64, key bytes). 64 bytes is still a lot. However, larger keys are needed for security, the hash functions themselves will need to change.
There is a potential issue here: If the long keys are ever stored as hashes in plain-text, this is equivalent to the keys themselves being stored in plain-text. According to citation below, this hasn’t been changed because of backwards compatibility concerns.
Of course, this also means that if the underlying hash functions are broken, HMAC would also be broken.
A good write up of this:
https://pthree.org/2016/07/29/breaking-hmac/
cite:
https://www.rfc-editor.org/errata/eid4809
Got to dig into a mystery. Night,
Lucas
Hi,
One bit I wanted to follow up is with an interesting HMAC issue. If the key used for HMAC is longer than the block size of the underlying hash function than a hash(key) is used instead.
This technically creates a collision: I have 2 keys, k and H(k), that create the same MAC. Therefore, I have a way to generate valid MACs for k without knowing what k is.
From my understanding, this decreases the security of HMACs using keys larger than block size, but in many scenarios not meaningfully so. If SHA256 is used, the number of bytes of security is min(64, key bytes). 64 bytes is still a lot. However, larger keys are needed for security, the hash functions themselves will need to change.
There is a potential issue here: If the long keys are ever stored as hashes in plain-text, this is equivalent to the keys themselves being stored in plain-text. According to citation below, this hasn’t been changed because of backwards compatibility concerns.
Of course, this also means that if the underlying hash functions are broken, HMAC would also be broken.
A good write up of this:
https://pthree.org/2016/07/29/breaking-hmac/
cite:
https://www.rfc-editor.org/errata/eid4809
Got to dig into a mystery. Night,
Lucas
No activity yet