leonetienne/GCrypt
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

readme

Browse Source
This commit is contained in:
Leonetienne 2022-02-08 01:17:56 +01:00
parent 986b5d870f
commit ecf4381cda
1 changed files with 3 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
readme.md
View File

@ -76,17 +76,17 @@ Without saying, this is more advanced and not as-easy as the methods supplied in
### Modes of operation ### Modes of operation
* [CBC] This block cipher makes use of cipher block chaining. Nothing special. * [CBC] This block cipher makes use of cipher block chaining. Nothing special.
* [IV] The initialization vector is indeed a bit of special sauce, as it depends on your key instead of being static. It is generated by running the feistel network on *E(m=seed, k=seed)*. * [IV] The initialization vector is indeed a bit of special sauce, as it depends on your key instead of being static. It is generated by running the feistel network on *E(m=seed, k=seed)*, which is a one-way function, because *m=k*.
* [RRKM] Never heard of a mode like this, so i've named it **R**olling**R**ound**K**ey**M**ode. This basically means that the round key extrapolation is carried out continously over EVERY round on EVERY block. So in addition to *M<sub>i</sub>* being dependent on *E(M<sub>i-1</sub>,K<sub>i-1,0</sub>)* due to CBC, so is now *K<sub>i</sub>* dependent on *K<sub>i-1,r</sub>* with *r* being the maximum number of extrapolated keys within a call of *E()*. This is handled within the feistel network class, as an instance lifecycle sees all blocks, if you want to take a peek. * [RRKM] Never heard of a mode like this, so i've named it **R**olling**R**ound**K**ey**M**ode. This basically means that the round key extrapolation is carried out continously over EVERY round on EVERY block. So in addition to *M<sub>i</sub>* being dependent on *E(M<sub>i-1</sub>,K<sub>i-1,0</sub>)* due to CBC, so is now *K<sub>i</sub>* dependent on *K<sub>i-1,r</sub>* with *r* being the maximum number of extrapolated keys within a call of *E()*. This is handled within the feistel network class, as an instance lifecycle sees all blocks, if you want to take a peek.
### Password to key ### Password to key
How does *GC* transform a password to a key? How does *GC* transform a password to a key?
First up, we have to establish what requirements this transformation must fulfill: First up, we have to establish what requirements this transformation must fulfill:
* A full key. Not just *len(passwd)\*8* bits and the rest zero-padded. * A full key. Not just *len(passwd)\*8* bits and the rest zero-padded.
* Even if *len(passwd\*8) > KEY_SIZE*, every bit of the password should affect the key * Even if *len(passwd)\*8 > KEY_SIZE*, every bit of the password should affect the key
* Ideally good collision resistance * Ideally good collision resistance
Let's be honest, I'm not a cryptographer, i have no idea how collision resistant this is. Let's be honest, I'm not a cryptographer, I have no idea how collision resistant this is.
This means, it has to be considered *insecure*! This means, it has to be considered *insecure*!
I have tried a few passwords brute-forcibly, experimentally (about 1mil) and have not been able to produce a collision. I have tried a few passwords brute-forcibly, experimentally (about 1mil) and have not been able to produce a collision.
Obviously there have to be collisions, since *|P|, len\(p\) &#8712; &#8501; &#8811; |C|*. Obviously there have to be collisions, since *|P|, len\(p\) &#8712; &#8501; &#8811; |C|*.