opened
WillSewell
username_0
The `cipher.Stream` interface can be wrapped in a `cipher.StreamReader` or `cipher.StreamWriter` for `io.Reader`/`io.Writer` implementations. It was be nice to have the same interface for `cipher.BlockMode`.

The challenge with `cipher.BlockMode` is that `CryptBlocks` must be run on byte slices whose lengths are multiples of the block size. I don't see this being a fundamental problem, but it will complicate the implementation. For the `Reade`, I imagine it would consist of two internal buffers as the state: `encrypted` to store encrypted  bytes read from the underlying reader, and `decrypted` to store decrypted bytes to by copy out whenever `Read` is called. It would operate in two phases: If `len(decrypted) == 0`, then call `Read` on the underlying `Reader` until there is at least `BlockSize` bytes in `encrypted`. Then we can decrypt as many blocks as possible from `encrypted` into `decrypted`, and return these whenever Read is called until `len(decrypted) == 0` again.

I haven't though as much about the Writer, but I suspect it will operate in a similar way.

The implementation is just a rough idea at the moment. I'm creating this issue mainly to see whether there is interest in the idea. If there is, I am happy to write a prototype.
Lack of Reader/Writer implementations for cipher.BlockMode
issue
created
bcmills
username_1
CC @username_4
comment
created
connesc
username_2
I have faced the same issue recently and ended up writing my own io.Reader and io.Writer.
Interest seems to be rather limited, but in case it can help, here is my package: [github.com/username_2/cipherio](https://github.com/username_2/cipherio).
comment
created
xaionaro
username_3
@username_4 : I saw @username_1 CC-ed you and no response followed. Hoping may be you just forgot to reply here and it is possible to get a comment on this?

Personally do not think we should think about specific implementation right now (as in the issue description), but IMHO it is still worth to decide if we should provide `io.Reader`/`io.Writer` for block ciphers (and properly handle paddings). It seems like pretty fundamental/basic thing (for example this padding handling is happening in `tls.Conn`).
comment
created
FiloSottile
username_4
We won't provide an easy to use API for unauthenticated block modes, because we don't want them to be easy to use.

Approximately no application should be directly using unauthenticated block (or stream) ciphers, as they let the attacker modify the message, which systematically leads to confidentiality breaks (such as with padding oracle attacks). They are just a building block for AEADs, which is what applications should use instead.

Applications that do need to handle streaming data should use chunked AEAD schemes, where each chunk is authenticated before being released, such as STREAM (#43774, https://github.com/golang/go/issues/49782#issuecomment-978776702).

/cc @golang/security
comment
closed
FiloSottile
username_4
issue
created
xaionaro
username_3
Thank you for the references. Will track the progress there.
comment