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

4
README.md
View File

@ -7,4 +7,6 @@ Currently `fcry` uses `ChaCha20Poly1305` ([RFC 8439](https://datatracker.ietf.or
Currently `fcry` is __not thoroughly tested__ and in __early stages of development__.
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
(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
Make the program real-world usable and stable.
## Required changes
* 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
* unit tests
* understand `encrypt_next_in_place()`s first argument better
## Knowledge and Design
* understand `encrypt_next_in_place()`'s first argument better
* current understanding:
* associated data is used for parts of the data that cannot be
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
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
* parallel processing: use all available (or configurable) CPU cores