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

Updated readme

Browse Source
This commit is contained in:
Leonetienne
2022-02-07 01:50:00 +01:00
parent 9413e686f3
commit 4d083e6acf
4 changed files with 145 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files

35
readme.md
View File

@@ -4,16 +4,16 @@
## What the hell is this?
An educational project on implementing a block cipher using a feistel network.
To provide at least some security this is using some DES-inspired modes of operation like *cipher block chaining*.
This way this provides relatively good diffusion.
This block cipher employs a few modes of operation. Read more about them [here](#modes-of-operation).
## Features
* It has very easy syntax
* It's slow
* It absolutely tanks your ram when working with files
* Even leaves some key fragments in there✨
* It's probably super insecure
* It leaves your keys sprinkled in ram✨
* 512-bit keys <sup>\*</sup>
* But the syntax is pythonlike easy🙇
* But the syntax is pythonlike easy🙇
It's pretty ghetto, you know?
@@ -71,6 +71,33 @@ Without saying, this is more advanced and not as-easy as the methods supplied in
---
<sup>\*</sup> A key is always of size `BLOCK_SIZE`. The default block size is 512 (bit), but you can easily change it in [Config.h](https://github.com/Leonetienne/GhettoCrypt/blob/master/GhettoCrypt/Config.h) or wherever it'll be put in the INCLUDE/*.cpp. `BLOCK_SIZE` is also the minimal output length!
## The deets 🍝
### Modes of operation
* [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)*.
* [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,K<sub>i-1,0</sub>)<sub>i-1</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
How does *GC* transform a password to a key?
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.
* Even if *len(passwd\*8) > KEY_SIZE*, every bit of the password should affect the key
* Ideally good collision resistance
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*!
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, because *|P|, len\(p\) &#8712; &#8501; &#8811; |C|*.
How does it work? Basically, what happens is your password gets recoded to binary. It is then split into blocks of
size KEY_SIZE, they are &xoplus; together, and this single block is then encrypted with itself as a key.
The end result is the key corresponding to your password.
This is a one-way operation. Since the key used for this operation is the cleartext itself, you cannot undo it without already
knowing the password(=cleartext) to begin with. *You could make a hashfunction out of this.*
## LICENSE
```
BSD 2-Clause License