On Thu, 2014-09-11 at 22:47 +0100, Matthew Toseland wrote: > On 11/09/14 22:42, Matthew Toseland wrote: > > In order to implement disk encryption in purge-db4o, I'm reviewing one > > of unixninja's crypto refactoring commits. This includes disk crypto but > > also some important crypto infrastructure providing a single hopefully > > clean API for our various different ciphers etc. I haven't looked at his > > other commits, so I don't know whether something else was intended ... > > > > Lots of the code abuses ByteBuffer.array(), making very bad assumptions > > about the ByteBuffer's passed in etc (not direct, not a slice, > > arrayOffset() == 0, etc etc); this is fixed. (No criticism intended, NIO > > is odd) > > > > CryptByteBuffer implements symmetric encryption: > > > > The main methods are: > > public ByteBuffer encrypt(byte[] input, int offset, int len) > > public ByteBuffer decrypt(byte[] input, int offset, int len) > > > > There are various wrappers e.g. ByteBuffer encrypt(ByteBuffer). This is > > highly ambiguous: Lots of NIO code takes a ByteBuffer and returns the > > same ByteBuffer. Here we are returning a different ByteBuffer. The > > original code wasn't clear whether it was always a new buffer or > > sometimes shared the array, anyway we have 3 requirements: > > 1. The API must be unambiguous. Ambiguity -> very bad bugs, e.g. stuff > > not getting encrypted. Hence e.g. we should not return a value if we are > > encrypting in place; this is convenient but ambiguous. > > 2. It needs to efficiently support encrypting in-place for big stuff: > > Whole packets, whole CHKs. > > 3. It needs to conveniently support small encryptions. These happen in > > e.g. setting up an EncryptedRandomAccessThing (new class used for > > encrypted random access tempfiles). > > > > Hence IMHO we should have: > > > > Base method: > > void encrypt(byte[] buf, int offset, int length) > > > > Main convenience methods: > > void encrypt(byte[] input, int offset, byte[] output, int outputOffset, > > int length) > > byte[] encryptCopy(byte[] input, int offset, int length) > > > > Along with the appropriate wrappers e.g. > > encrypt(ByteBuffer input, ByteBuffer output) > > Which should work with direct ByteBuffer's, and should encrypt the > > gettable part of the input and put it to the output. > I.e. it should not encrypt parts of the backing array that are not part > of the ByteBuffer. E.g. ByteBuffer.equals() only considers the get()able > part of the ByteBuffer, from the position to the capacity. All I'm > saying there is we should use ByteBuffer's properly and not just pretend > that they always have a backing array etc. Of course we can optimise the > encryption if they do have one. But then we can optimise it in a > different way if it's direct: Get from a ByteBuffer to a byte[], aligned > with the block size, encrypt it, put to the other ByteBuffer.
All of the above sounds sane to me, provided we always use stream ciphers (or a mode that emulates them). At the moment that's the case, so I guess it will do :) Florent
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
