Hi! ~~~ On 03/15/2012 03:41 PM, Tankred Hase wrote: > Hi Carsten, > > I would like to do deduplication on the server through convergent encryption > on the client: http://www.ssrc.ucsc.edu/Papers/storer-storagess08.pdf > <http://www.ssrc.ucsc.edu/Papers/storer-storagess08.pdf> > > This is basically what most services such as Wuala and Bitcasa do in order to > save storage. Basically it means, that you to derive the symmetric encryption > key from the file through a cryptographic hash function e.g. SHA1. This way > encryption is deterministic and two users will always encrypt the same file > to the same ciphertext. The pros and cons of this approach are discussed in > the paper. But the tradeoff seems fairly decent. > > I would like to try it using the symmetric encryption primitives in > OpenPGP.js (mainly because it's the fastest js crypto I've seen so far). I > just want to make sure that I'm using the correct function. Right now I'm > using 'openpgp_crypto_symmetricEncrypt' and it seems to work. But I have a > few questions... > > 1. What is the 'openpgp_cfb' parameter do? It only works when it is set to > '0' >
Its a boolean and should work for both. Basically it enables the Resync after prefix encryption. OpenPGP has its own "strange" CFB Mode to encrypt data. (http://tools.ietf.org/html/rfc4880#section-13.9). As a side note: This resync is only used when encrypting without integrity protection (the difference between Tag 18 packet and Tag 9 packet) > 1. Is 'prefixrandom' like an initialization vector? If so, I can't choose > it randomly for deterministic encryption for obvious reasons. So I also > derive it from the sha1 hash right now. Need to research how to do this > correctly though. > The IV is not random, its all zero. Instead the encrypted data is prefixed by [cipher-block-size]-bytes plus the 2 bytes for a sanity check. See RFC 4880: The data is encrypted in CFB mode, with a CFB shift size equal to the cipher's block size. The Initial Vector (IV) is specified as all zeros. Instead of using an IV, OpenPGP prefixes a string of length equal to the block size of the cipher plus two to the data before it is encrypted. The first block-size octets (for example, 8 octets for a 64-bit block length) are random, and the following two octets are copies of the last two octets of the IV. For example, in an 8-octet block, octet 9 is a repeat of octet 7, and octet 10 is a repeat of octet 8. In a cipher of length 16, octet 17 is a repeat of octet 15 and octet 18 is a repeat of octet 16. As a pedantic clarification, in both these examples, we consider the first octet to be numbered 1. After encrypting the first block-size-plus-two octets, the CFB state is resynchronized. The last block-size octets of ciphertext are passed through the cipher and the block boundary is reset. > 1. Does the following implementation make sense using the function? > > > // aes encrypt with key_size 128 bit > var sha1 = str_sha1(message); > var key = sha1.substr(0, 16); // first 16 bytes > var prefix = sha1.substr(4, 16); // last 16 bytes > var ct = openpgp_crypto_symmetricEncrypt(prefix, 7, key, message, 0); > var pt = openpgp_crypto_symmetricDecrypt(7, key, ct, 0); Well. As specified the prefix should be secure random. I can't tell you if this usage of partial key bytes is secure or not. The prefix length should be the block size. openpgp_cfb_encrypt already adds the 2 bytes for the sanity check. best regards, carsten _______________________________________________ http://openpgpjs.org
