C For C's Sake

[An Attack on CFB Mode Encryption As Used By OpenPGP](https://eprint.iacr.org/2005/033.pdf), unclear to me how this was mitigated. EDIT: https://tools.ietf.org/html/rfc4880#page-84 seems like it wasn't mitigated. EDIT2: more details: https://github.com/google/end-to-end/issues/151

I started implementing this thing now. Handkerchiefs and soothing words very welcome.

From RFC 4800: > There are many cases in cryptographic engineering > where the implementer must use care and wisdom, and this is one. GnuPG maintains a list of applications...

`opgp decrypt --sk my.secret.key encrypted.message.asc` now works \o/

`opgp encrypt --pk me.pk plaintext.file > encrypted.asc && opgp decrypt --sk me.sk encrypted.asc` now works. `gpg` complains about `gpg: public key decryption failed: Wrong secret key used`, still haven't figured...

- encryption/decryption from/to `gpg` now works - Technically speaking OpenPGP seems to allow arbitrary nesting of compressed/encrypted/signed packets (`RFC 4480: 11.3`); I'm inclined to refrain from supporting that. - some...

thank you @randombit ! It also looks like they have good test coverage!

The new and fantastic `keybox` format used by GnuPGv2 seems to be ... undocumented. Using old-style `pubring.gpg` (which is just a sequence of __transferable public keys__ in binary format, concatenated...

Follow this https://github.com/hashbang/git-signatures/issues/12

- I just got rid of the `~hashp` code last night. :( - The problem here is that commit 555d2fe99b32481801bbfeb346b0b87dc122c7c0 fucked Mirage-support, and then there was a flurry of follow-up...