I'm confused. Even with Tag's 18/19 which can verify modification, doesn't the ascii armor still have to use a radix 64 (base64 data+crc24)? I looked over the RFC again, and don't seem to see that the crc is optional for armoring text? I could just be missing something though.
I was looking at the CRC24 method yesterday. So, I think the issue comes from the fact that we're looping over lots of data, and looping 8 times for each entry. I think what we need to do is build a lookup table for CRC24. I was looking around to see if other CRC's had lookup tables or other optimizations some of them do. http://wiki.osdev.org/CRC32 Describes one method for CRC32 that could be adjusted for building a similar table for CRC24. Thoughts? Sean On Fri, Feb 17, 2012 at 7:40 AM, Carsten Wentzlow <[email protected] > wrote: > Hi! > ~~~ > > On 02/17/2012 12:37 AM, Tankred Hase wrote: > > > > Hi Carsten, thanks for your reply. > > > > > Well, a very easy way to do this is to abstract the symmetric > encryption / decryption routine (openpgp_crypto_symmetricEncrypt and > openpgp_crypto_symmetricDecrypt) into a worker. These functions are not > requiring any additional secure random or reading from the storage so a > worker wrapper implementation should be straightforward. > > > > When profiling the encryption of a 700kb file only about 4% of the time > is spent in openpgpg_crypto_symmetricEncrypt. About 27% is spent in > createcrc24. > > > > Wow, ok. We need a better crc24 implementation. The crc24 checksum is > calculated over the data encoded in base64. The checksum is at the end of > each "ascii armored" pgp block encoded in base64. In the early days this > was used for verifying integrity of the encrypted data. In RFC4880 the > Modification Detection Code Packet (Tag 19) and the Sym. Encrypted > Integrity Protected Data Packet (Tag 18) have been introduced allowing a > integrity protection based on a sha1 hash stored in the tag 19 packet. If > openpgp.config.config.integrity_protect is set to true openpgpjs generates > these two packets. > > I would suggest to remove the getCheckSum() and verifyCheckSum() from > openpgp_encoding_deArmor / openpgp_encoding_armor in > src/encoding/openpgp.encoding.asciiarmor.js within your code. > > > > > Another problem of the current implementation with big impact on > performance is the conversion between byte (int 0-255) array and string. I > often made use of the two conversion functions bin2str and str2bin to feed > data in the correct format into libraries. I think we should internally > change this behavior to only using arrays of integers after base64 decoding > has been done. > > > > Im passing files in the form of a base64 encoded dataUrl to > openpgp.write_encrypted_message. What would be the best input type im terms > of performance? > > > > openpgp.write_encrypted_message only accepts strings as data input. The > comment on arrays vs. strings and conversion described an internal behavior > of the implementation. > > regards, > carsten > > _______________________________________________ > > http://openpgpjs.org >
_______________________________________________ http://openpgpjs.org
