Adjust links in readme
This commit is contained in:
Leonetienne
parent
74883458ba
commit
309dacadc8
38
readme.md
38
readme.md
@ -113,7 +113,7 @@ Without saying, this is more advanced and not as-easy as the methods supplied in
|
||||
|
||||
### Password to key
|
||||
How does GCrypt transform a password to a key?..
|
||||
Well, it uses the included hash function [GHash](https://gitea.leonetienne.de/leonetienne/GCrypt/src/branch/feature/relaunch/GCryptLib/include/GCrypt/GHash.h).
|
||||
Well, it uses the included hash function [GHash](https://gitea.leonetienne.de/leonetienne/GCrypt/src/branch/master/GCryptLib/include/GCrypt/GHash.h).
|
||||
|
||||
### Hashing with GHash
|
||||
GHash is a streaming hash function based on the GCipher.
|
||||
@ -128,7 +128,7 @@ GHash also supports a do-it-all wrapper method that takes a Flexblock (A block o
|
||||
This wrapper function adds an additional block including the length of the input. This wrapper function is used to transform Passwords to Keys.
|
||||
|
||||
### GPrng...?
|
||||
Whilst we're at it, why not implement a pseudo-random number generator based on GHash aswell. So here it is, [GPrng](https://gitea.leonetienne.de/leonetienne/GCrypt/src/branch/feature/relaunch/GCryptLib/include/GCrypt/GPrng.h).
|
||||
Whilst we're at it, why not implement a pseudo-random number generator based on GHash aswell. So here it is, [GPrng](https://gitea.leonetienne.de/leonetienne/GCrypt/src/branch/master/GCryptLib/include/GCrypt/GPrng.h).
|
||||
GPrng is really nothing special. I just wanted to implement it, mainly to visualize the GCiphers entropy.
|
||||
|
||||
GPrng basically does the following: It creates a GHash instance, which initially digests the prng's seed. This produces a hash result, which is one block in size.
|
||||
@ -140,30 +140,30 @@ future output.
|
||||
#### Single-block diffusion
|
||||
`"Hello :3"` in binary, and it's ciphertext:
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Now, let's flip a single bit in the input:
|
||||
|
||||
One bit flipped, and again the corresponding ciphertext:
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Let's gif them together, to better see the difference:
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
As shown, flipping even a single bit, affects the entire ciphertext.
|
||||
|
||||
#### What about input longer than a single block?
|
||||
|
||||
Input, and ciphertext:
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Notice how the ciphertext doesn't change until the block containing the bitflip is reached? This is a limitation of cipher block chaining.
|
||||
|
||||
@ -171,11 +171,11 @@ Notice how the ciphertext doesn't change until the block containing the bitflip
|
||||
How non-transparent is the cipher with extreme inputs? Even with a super problematic key?:
|
||||
|
||||
Input, key, and ciphertext:
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Notice how even cleartexts that are completely uniform, with a key that is almost just zeores, will still produce ambiguous ciphertexts.
|
||||
|
||||
@ -183,18 +183,18 @@ Notice how even cleartexts that are completely uniform, with a key that is almos
|
||||
Check it out, here are the distributions of a few different getter-methods, some in black/white, some in grayscale, some in color.
|
||||
|
||||
Blackwhite - GetBit(), Grayscale - GetRandom<T>(), and Grayscale - operator():
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Color - GetRandom<T>(), Color - operator(), and Color - GetBlock():
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## Noteworthy:
|
||||
* This is no fixed algorithm. Newer versions may very well be unable to decrypt ciphertexts encrypted with earlier versions.
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user