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.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Devl mailing list [email protected] https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
