Timeline for Public key encryption and big files with NaCL
Current License: CC BY-SA 3.0
23 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jan 4, 2016 at 20:45 | comment | added | Jack O'Connor | If you want to detect truncation, but you don't want to require knowing the file size in advance, another option is to encrypt an empty chunk at the end. | |
| Dec 28, 2015 at 18:01 | answer | added | Jack O'Connor | timeline score: 4 | |
| Jan 19, 2015 at 15:57 | comment | added | Tarek Ziadé | @CodesInChaos yes. so yea your proposal to use the file size makes a lot of sense, alongside the counter | |
| Jan 19, 2015 at 14:23 | comment | added | CodesInChaos | Do you know how big the file is before you encrypt it? | |
| Jan 19, 2015 at 10:53 | history | edited | Tarek Ziadé | CC BY-SA 3.0 |
deleted 60 characters in body
|
| Jan 19, 2015 at 10:45 | comment | added | Tarek Ziadé | The security model I use is described here: nacl.cr.yp.to/box.html (security model section) "The sender and receiver are nevertheless protected against forgeries by other parties." - I will clarify my initial question. Thanks for the feedback | |
| Jan 19, 2015 at 8:14 | comment | added | user991 | No, public "key encryption is done with" ["the target public key"] and randomness and the message. $\:$ Signcryption adds in "the source private key" so that "the decryption step" will ensure "mutual authentication", which will guarantee that "the chunks are not forged". $\:$ You "need to add an extra step" into your question so that people know you're using signcryption rather than just PKE. $\;\;\;\;$ | |
| Jan 19, 2015 at 7:55 | comment | added | Tarek Ziadé | @RickyDemer reading back some crypto doc. I am confused why I need to verify the chunks. Public key encryption is done with the source private key and the target public key, and the decryption step ensures mutual authentication. So that guarantees the chunks are not forged. Why do I need to add an extra step here ? | |
| Jan 18, 2015 at 12:30 | comment | added | Tarek Ziadé | ok thx - will look at this | |
| Jan 18, 2015 at 10:25 | comment | added | user991 | You should MAC an ordered pair that indicates the autoinc and the ciphertext. $\;$ | |
| Jan 18, 2015 at 10:22 | comment | added | Tarek Ziadé | @RickyDemer so what should I do ? | |
| Jan 17, 2015 at 9:26 | comment | added | user991 | "being able to decrypt it" certainly doesn't verify it, especially since the encryption is public key. $\hspace{.6 in}$ | |
| Jan 17, 2015 at 9:05 | comment | added | Tarek Ziadé | @RickyDemer since it's encrypted with the pub/priv key pair, being able to decrypt it verifies it, no ? or do you mean something specific? | |
| Jan 16, 2015 at 14:24 | comment | added | user991 | Verifying "the order of chunks" is not enough; you should also verify the chunks. $\;$ | |
| Jan 16, 2015 at 14:11 | comment | added | Tarek Ziadé | Hbas, the hash was replaced by an autoinc, that is added to the data before encryption, so as far as I get it, this prevents tampering. I am also planning to add the total number of chunks so none can be appended | |
| Jan 16, 2015 at 12:32 | comment | added | Hbas | In your solution, if a malicious user is able to tamper with/replace your contents (encrypted chunk), it is not clear if he is also able to replace the hash. Unless you are transmiting/storing that separatedly, the hash is not improving your security... =) | |
| Jan 16, 2015 at 8:03 | history | edited | Tarek Ziadé | CC BY-SA 3.0 |
added 180 characters in body
|
| Jan 15, 2015 at 16:49 | comment | added | Tarek Ziadé | Thx - will read up | |
| Jan 15, 2015 at 16:48 | comment | added | CodesInChaos | 1) Salsa20 is a stream cipher, so nonce reuse behaves like one-time-pad key-reuse. crypto.stackexchange.com/… 2) The Poly1305 MAC is a one-time MAC (wegman-carter), so nonce reuse leaks the MAC key for that nonce. | |
| Jan 15, 2015 at 16:46 | comment | added | Tarek Ziadé | I used the same nonce through the whole process. Can you explain me why it is fatal in this case ? (or if you have a good link) - thanks for the feedback | |
| Jan 15, 2015 at 16:45 | comment | added | CodesInChaos | 1) Do you use a two part nonce, so you can use a different counter as nonce input for each chunk? Reusing the full nonce is fatal. 2) It's essential to use a special counter/nonce for the chunk containing the hash 3) I'd replace the hash by the file size | |
| Jan 15, 2015 at 16:43 | review | First posts | |||
| Jan 15, 2015 at 18:48 | |||||
| Jan 15, 2015 at 16:39 | history | asked | Tarek Ziadé | CC BY-SA 3.0 |