ddidderr/fcry
1
0
Fork 0
Code Issues 2 Pull Requests Projects Releases Wiki Activity

(docs) updated TODO and README to clarify project status

Browse Source
This commit is contained in:
ddidderr 2022-04-10 21:30:01 +02:00
parent d7e86d8f88
commit 668e726c21
Signed by: ddidderr
GPG Key ID: 3841F1C27E6F0E14
2 changed files with 15 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
README.md
View File

@ -8,3 +8,5 @@ Currently `fcry` is __not thoroughly tested__ and in __early stages of developme
There is a chance, that something is broken as of now. There is a chance, that something is broken as of now.
Encryption __seems__ to work, but due to a possible lack of understanding of some underlying methods Encryption __seems__ to work, but due to a possible lack of understanding of some underlying methods
(or misinterpretation) it could theoretically be not effective at all. (or misinterpretation) it could theoretically be not effective at all.
See [TODO.md](/ddidderr/fcry/src/branch/main/TODO.md) for further information.

20
TODO.md
View File

@ -2,19 +2,23 @@
## Summary ## Summary
Make the program real-world usable and stable. Make the program real-world usable and stable.
## Required changes ## Knowledge and Design
* password hashing * understand `encrypt_next_in_place()`'s first argument better
* configurable algorithm (sane default)
* configurable nr of rounds (sand default)
* a way to enter the password securely in a prompt while still being able to handle `stdin` data
* add usage examples to README.md
* unit tests
* understand `encrypt_next_in_place()`s first argument better
* current understanding: * current understanding:
* associated data is used for parts of the data that cannot be * associated data is used for parts of the data that cannot be
encrypted but should also be integrity protected by the authentication tag encrypted but should also be integrity protected by the authentication tag
* since there are no parts that cannot be encrypted in the context of `fcry` it is correct * since there are no parts that cannot be encrypted in the context of `fcry` it is correct
to pass an empty slice to the first argument of `encrypt_next_in_place()` to pass an empty slice to the first argument of `encrypt_next_in_place()`
* currently `fcry` uses 64 KiB blocks as single AEAD messages
* as stated [here](https://pycryptodome.readthedocs.io/en/latest/src/cipher/chacha20_poly1305.html) (limit of 13 billion messages) would imply a maximum file-size of `64 KiB * 13e9 = 832e9 KiB = 774.86 TiB`. While a file this size could be considered a special (and unsupported) use case anyway, performance is also a consideration. Does performance improve noticably with larger message sizes?
* unit tests
## Features
* password hashing
* configurable algorithm (sane default)
* configurable nr of rounds (sand default)
* a way to enter the password securely in a prompt while still being able to handle `stdin` data
* add usage examples to README.md
# Roadmap 2.0 # Roadmap 2.0
* parallel processing: use all available (or configurable) CPU cores * parallel processing: use all available (or configurable) CPU cores