… options

Fix: canonizing of literal data for encrypted messages

Private key encryption

add SerializePrivate without sign function

update private key serializer

X25519 keygen

Work around OpenPGP.js bug encrypting ECDH messages

Fix panic when decrypting session key with the wrong private key

The first chunk has to be at least 512 bytes per spec, and very
large amounts (e.g. 10MB) of tiny chunks hang both this library
and OpenPGP.js when reading.

Buffer partialLengthWriter to write in chunks of >= 512 bytes

Fix missing leading zeros in ECDH messages

Use latest-created valid self-signature

Also, verify that the algorithm mentioned in the header matches
the algorithm used in the signature.

Security fixes

See 5bcbe46.

…ure.SigExpired

See b4956d3.

Fix tests; merge golang/master

Also, accept no headers at all, defaulting to MD5.

* Fix for KeyID digest generation

ProtonMail/gopenpgp#10

* Better solution

* Fix bitLength when first byte is zero

* Use encoding.NewMPI in NewECDSAPublicKey; remove NewMPIWithBitLength

* Use Len8 instead of Len to get the bit length of a byte

* Don't serialize leading zeros in MPIs

* Properly handle MPIs with leading zeros

* Remove unused MPI functions

GNU defines an extension to the S2K algorithms where the private
key of a PGP is missing and only subkeys are present. These
incomplete keys are useful in scenarios where a user distributes
various subkeys to individual places (e.g. various build servers)
while retaining the master key. Picking up https://go-review.googlesource.com/c/crypto/+/32797/
after it was abandoned.

The extension is described at: http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=blob;f=doc/DETAILS;h=fe55ae16ab4e26d8356dc574c9e8bc935e71aef1;hb=23191d7851eae2217ecdac6484349849a24fd94a#l1109

Change-Id: I2de52a4f86b113eb7debf92579a6f79836d86c3c

Store S2K parameters in a new s2k.Params struct, instead of in a
s2k.Config, so that we can properly re-serialize them.

And V5 Symmetrically Encrypted Data Packets (which use AEAD as well).

To enable AEAD when encrypting messages symmetrically, pass:

    &packet.Config{
        AEADConfig: &packet.AEADConfig{}
    }

to `openpgp.EncryptSymmetrically`. To enable AEAD when using public-key
cryptography, pass the same config to `openpgp.NewEntity` to announce
support for AEAD in the newly generated key. This library will
automatically use AEAD when encrypting to keys that claim to support it.

It is also possible to change the AEAD mode that is used when encrypting
symmetrically, or the preferred AEAD mode when generating a key, by
passing:

        AEADConfig: &packet.AEADConfig{
            DefaultMode: packet.AEADModeEAX
        }

`AEADModeEAX` is the default. The other options are `AEADModeOCB` and
`AEADModeExperimentalGCM`. The latter is a private/experimental
algorithm, and not defined in the spec. It is also supported by
OpenPGP.js, but not, at the moment, GPG. It is typically the most
performant option, as GCM is implemented in asm.

And finally, when encrypting (either symmetrically or asymmetrically),
it is also possible to pass the chunk size that is used:

            ChunkSize: 1 << 10 // 1KiB

A smaller chunk size means that, when en/decrypting a stream, you'll
receive data sooner (and more often). It also means a marginally bigger
overhead (16 bytes per chunk). The default is 256KiB, which we feel
strikes a decent balance, although that might not be the case for
gigantic messages. The passed chunk size is rounded down to the closest
power of two and clamped between 64 bytes and 128 MiB.
(According to the spec, chunk sizes larger than 128 MiB (1 << 27 bytes)
SHOULD NOT be used, although the packet format allows it.)

Note: when using SerializeSymmetricKeyEncryptedReuseKey, one must now
set a non-nil config.AEADConfig when used with an AEAD Encrypted Data
Packet, and similarly one must call SerializeAEADEncrypted after calling
SerializeSymmetricKeyEncryptedReuseKey with a non-nil config.AEADConfig.

See https://tools.ietf.org/html/draft-ietf-openpgp-rfc4880bis-08.

Go 1.10 fails because it's missing golang/go@4d44a87.

Merge branch 'change-191658-4' from
https://go-review.googlesource.com/c/crypto/+/191658.

Note: on our side, this merge commit also:
- Removes SerializePrivateNoSign in favor of the new
  SerializePrivateWithoutSigning.
- Removes SelfSign (NewEntity already self-signs, although
  it used to be buggy, but this has been fixed).
- Un-exports SerializeEncrypted and SerializeUnEncrypted.
- Adds a serializeDummy function, and reorders the
  serializeEncrypted and serializeUnencrypted functions.

On the incoming side, this merge commit also:
- Replaces PrivateKey.Dummy with a PrivateKey.Dummy()
  function, which reads from the stored s2kParams property
  (which upstream doesn't have).
- Reorders the serializePrivate, SerializePrivate and
  SerializePrivateWithoutSigning functions, and updates the
  comments of the latter two.

Also, refactor NewEntity, separating signing/encryption key generation.
This way, we can reuse the code for adding subkeys.

Also, use NewSignerPrivateKey instead of New{RSA,EdDSA}PrivateKey,
and add NewDecrypterPrivateKey to replace New{RSA,ECDH}PrivateKey.

Also, use pointers instead of values for EdDSA PrivateKey and PublicKey,
for consistency with the other algorithms.

…ionSubkey methods to Entity (#53)

The existing implementation does not support operations on subkeys using
the library, so the following changes have been made to support subkey
interactions as per RFC 4880 (https://tools.ietf.org/html/rfc4880).

1. AddSigningSubkey and AddEncryptionSubkey add support for generating
new subkeys associated with an entity.
2. RevokeKey generates a key revocation signature for an entity.
3. RevokeSubkey generates a subkey revocation signature for a subkey.
4. Add Revocation reason subpacket and EmbeddedSignature subpacket to
output subpackets with corresponding tests.
5. Re-sign the embedded signatures for subkeys in entity.SerializePrivate().

Fixes golang/go#29301

Change-Id: If8ee111e825c17ccaa19e4afbac4a756671d9bf5