switch to go-buffer-pool #24
Conversation
We can xor in-place (this is what secio does).
It has a nicer interface and we don't even need the rest of the msgio stuff.
ghost
assigned 
| if n > 0 { | ||
| c.readS20.XORKeyStream(out[:n], in[:n]) // decrypt to out buffer | ||
| c.readS20.XORKeyStream(out[:n], out[:n]) // decrypt to out buffer |
There was a problem hiding this comment.
This is the only real change I made. This works, I just have no idea why we didn't do this in the first place (I have a feeling it was a vague security concern but, at worse, we'll end up exposing encrypted bytes that have been sent over the network so I'm not exactly concerned).
There was a problem hiding this comment.
Because we're now reading the encrypted bytes onto the buffer that's passed in by the caller, right? How would that be insecure? With salsa20, if you know the encrypted bytes and the decrypted bytes, can you crack the key?
There was a problem hiding this comment.
With salsa20, if you know the encrypted bytes and the decrypted bytes, can you crack the key?
No. Really, this should be fine. According to @Kubuxu, the docs used to be unclear on whether or not using the same buffer was safe (from a logic standpoint).
There was a problem hiding this comment.
It was cleared up last year: golang/crypto@74b34b9#diff-f7d579dda2d6d9536050719abf92604aL31 in September, I was writing this in May.
| if n > 0 { | ||
| c.readS20.XORKeyStream(out[:n], in[:n]) // decrypt to out buffer | ||
| c.readS20.XORKeyStream(out[:n], out[:n]) // decrypt to out buffer |
There was a problem hiding this comment.
Because we're now reading the encrypted bytes onto the buffer that's passed in by the caller, right? How would that be insecure? With salsa20, if you know the encrypted bytes and the decrypted bytes, can you crack the key?
I asked because I didn't want to bug Kubuxu but I realized I probably should anyways, in case I was missing something. |
It has a nicer interface and we don't even need the rest of the msgio stuff.
Prereq of libp2p/go-msgio#9