From 668e726c2195f2af2282b3bf339f5aa356744632 Mon Sep 17 00:00:00 2001 From: ddidderr Date: Sun, 10 Apr 2022 21:30:01 +0200 Subject: [PATCH] (docs) updated TODO and README to clarify project status --- README.md | 4 +++- TODO.md | 20 ++++++++++++-------- 2 files changed, 15 insertions(+), 9 deletions(-) diff --git a/README.md b/README.md index ab3f17d..e618004 100644 --- a/README.md +++ b/README.md @@ -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. \ No newline at end of file +(or misinterpretation) it could theoretically be not effective at all. + +See [TODO.md](/ddidderr/fcry/src/branch/main/TODO.md) for further information. \ No newline at end of file diff --git a/TODO.md b/TODO.md index 915a291..163ac61 100644 --- a/TODO.md +++ b/TODO.md @@ -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