You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Often you simply want to create or read from a file. Implementing this logic over and over
again is tedious and error prone. Therefore, the io/ioutil provides some helper functions like WriteFile(...)
I suggest a similar sio/sioutil package containing some commonly required functionality.
I suspect encrypting and decrypting a file are function candidates. However, I'm not sure right now which concepts should belong to sioutil and which shouldn't.
For example, a file can be encrypted with a password (deriving a key using a PBKDF - like Argon2id) or with a symmetric master key (which may be derived from a password itself) or with a public key (e.g. using ECDH to derive a secret key). Depending on the approach the encrypted file is created in a more open or closed format. For instance the file can start with a cipher id identifying the PBKDF + (fixed) parameters and the AEAD or the file can contain all parameters - like the PBKDF memory cost a.s.o.
Therefore, I suspect that a sio/sioutil is quite useful even though I cannot determine which functionality it should contain right now.
How do you want to solve it?
Currently, I'm thinking of:
EncryptFile(password []byte, filename string, data []byte, perm os.FileMode) error
aead
changed the title
provide helper functions similar to the io/iotuil package
provide helper functions similar to the io/ioutil package
May 24, 2019
This commit introduces the `sioutil` package.
It contains just a `NopCloser` method that is
related to https://golang.org/pkg/io/ioutil/#NopCloser.
It wraps a io.Writer and returns a io.WriteCloser that
does nothing on Close().
This is useful when en/decrypting an io.Writer but completing
the en/decryption process should not close the sink.
For example:
```
ew := s.EncryptWriter(sioutil.NopCloser(w), nonce, associatedData)
defer ew.Close() // This does not close 'w'.
```
updates #7
This commit introduces the `sioutil` package.
It contains just a `NopCloser` method that is
related to https://golang.org/pkg/io/ioutil/#NopCloser.
It wraps a io.Writer and returns a io.WriteCloser that
does nothing on Close().
This is useful when en/decrypting an io.Writer but completing
the en/decryption process should not close the sink.
For example:
```
ew := s.EncryptWriter(sioutil.NopCloser(w), nonce, associatedData)
defer ew.Close() // This does not close 'w'.
```
updates #7
What is the problem you want to solve?
Often you simply want to create or read from a file. Implementing this logic over and over
again is tedious and error prone. Therefore, the
io/ioutil
provides some helper functions likeWriteFile(...)
I suggest a similar
sio/sioutil
package containing some commonly required functionality.I suspect encrypting and decrypting a file are function candidates. However, I'm not sure right now which concepts should belong to
sioutil
and which shouldn't.For example, a file can be encrypted with a password (deriving a key using a PBKDF - like Argon2id) or with a symmetric master key (which may be derived from a password itself) or with a public key (e.g. using ECDH to derive a secret key). Depending on the approach the encrypted file is created in a more open or closed format. For instance the file can start with a cipher id identifying the PBKDF + (fixed) parameters and the AEAD or the file can contain all parameters - like the PBKDF memory cost a.s.o.
Therefore, I suspect that a
sio/sioutil
is quite useful even though I cannot determine which functionality it should contain right now.How do you want to solve it?
Currently, I'm thinking of:
EncryptFile(password []byte, filename string, data []byte, perm os.FileMode) error
DecryptFile(password []byte, filename string) ([]byte, error)
Also a
NopCloser(w io.Writer) io.WriteCloser
may be useful to avoid closing the underlyingio.Writer for
Enc/DecWriter
in some situations.Additional context
Are there alternative solutions?
Let users implement this logic themself. But - as mentioned - this is tedious and error prone.
Would your solution cause a major breaking API change?
No
Anything else that is important?
Getting feedback from actual users would be quite helpful.
The text was updated successfully, but these errors were encountered: