More README
This commit is contained in:
parent
b87c21b0e2
commit
9736a10e2e
2
.gitignore
vendored
2
.gitignore
vendored
|
@ -1,4 +1,4 @@
|
||||||
notes/
|
notes/
|
||||||
./run.sh
|
run.sh
|
||||||
./dethnote
|
./dethnote
|
||||||
./dethnote.exe
|
./dethnote.exe
|
||||||
|
|
52
README.md
52
README.md
|
@ -138,3 +138,55 @@ ever in the application's working memory.
|
||||||
|
|
||||||
Only when access has been fully granted to decrypt the message will the
|
Only when access has been fully granted to decrypt the message will the
|
||||||
`message.bin` file be opened.
|
`message.bin` file be opened.
|
||||||
|
|
||||||
|
## Zero Admin Visibility
|
||||||
|
|
||||||
|
The admin of the web server has zero visibility into any of the data in
|
||||||
|
the service.
|
||||||
|
|
||||||
|
* The filesystem is just full of hexadecimal path names leading to
|
||||||
|
files encrypted with AES-256.
|
||||||
|
* No e-mail addresses are visible to the admin, because those are stored
|
||||||
|
_inside_ those encrypted files.
|
||||||
|
* The admin can't snoop on other peoples messages because they are _very_
|
||||||
|
heavily encrypted:
|
||||||
|
* Strong Diceware pass phrases that would resist brute force attacks
|
||||||
|
for millions of years even with a fast hashing algorithm.
|
||||||
|
* Dethnote uses the bcrypt hashing algorithm with a slow iteration
|
||||||
|
count making brute forcing all the harder.
|
||||||
|
* The admin can't enumerate what passwords _even exist_. All he can see
|
||||||
|
is the hexadecimal data paths, but doesn't know what the passwords are,
|
||||||
|
and can't even tell _whose_ files belong to _who_. And brute forcing
|
||||||
|
random Diceware passwords is practically impossible.
|
||||||
|
|
||||||
|
## Robustness and "Offline Mode"
|
||||||
|
|
||||||
|
This service relies heavily on a reliable e-mail server for sending out
|
||||||
|
verification e-mails, Decryption Routine warning e-mails, and so-on.
|
||||||
|
|
||||||
|
But this is the real world and web servers aren't always reliable.
|
||||||
|
|
||||||
|
On the web, the service will naturally self-test the e-mail system:
|
||||||
|
before you can decrypt a note, you have to verify an e-mail address.
|
||||||
|
This ensures that the e-mail system is working, so that when the
|
||||||
|
Decryption Routine begins, it will be able to send an e-mail to the
|
||||||
|
note owner.
|
||||||
|
|
||||||
|
But I mainly wrote this service for myself, and so it has an "Offline
|
||||||
|
Mode" that works in absence of a running web server or e-mail configuration.
|
||||||
|
|
||||||
|
My web server backs up to my desktop PC at home, and so there will always
|
||||||
|
be a copy of _this application_ and its database of encrypted notes there.
|
||||||
|
The command line interface of the program allows you to immediately decrypt
|
||||||
|
and open a note _that you have a password for_. Example:
|
||||||
|
|
||||||
|
```bash
|
||||||
|
# Open a note with this password:
|
||||||
|
% dethnote -open "viewable require broom taunt spoiled"
|
||||||
|
Here is the contents of the note!
|
||||||
|
```
|
||||||
|
|
||||||
|
Note that this doesn't change any of the security considerations of the
|
||||||
|
service. The passwords are still just as hard to brute force. All this
|
||||||
|
"offline mode" does is bypass the need for e-mail validation and
|
||||||
|
minimum timeouts before opening notes.
|
||||||
|
|
Loading…
Reference in New Issue
Block a user