On Tue, May 12, 2020 at 4:03 PM David Howells wrote:
>
> Jason A. Donenfeld wrote:
>
> > So long as that ->update function:
> > 1. Deletes the old on-disk data.
> > 2. Deletes the old key from the inode.
> > 3. Generates a new key using get_random_bytes.
> > 4. Stores that new key in the inode.
Jason A. Donenfeld wrote:
> So long as that ->update function:
> 1. Deletes the old on-disk data.
> 2. Deletes the old key from the inode.
> 3. Generates a new key using get_random_bytes.
> 4. Stores that new key in the inode.
> 5. Encrypts the updated data afresh with the new key.
> 6. Puts the
Hi David,
So long as that ->update function:
1. Deletes the old on-disk data.
2. Deletes the old key from the inode.
3. Generates a new key using get_random_bytes.
4. Stores that new key in the inode.
5. Encrypts the updated data afresh with the new key.
6. Puts the updated data onto disk,
then
Jason A. Donenfeld wrote:
> - /* no ->update(); don't add it without changing big_key_crypt() nonce */
> + /* no ->update(); don't add it without changing chacha20poly1305's nonce
Note that ->update() doesn't have to modify the contents of the key, but can
just rather replace them
A while back, I noticed that the crypto and crypto API usage in big_keys
were entirely broken in multiple ways, so I rewrote it. Now, I'm
rewriting it again, but this time using the simpler ChaCha20Poly1305
library function. This makes the file considerably more simple; the
diffstat alone should
5 matches
Mail list logo
