[Autocrypt] How to create the "raw key" part from an RSA key

[Bjoern]

Okay, I figured out how to get the correct public key part.

Now, I am a little bit confused about which data are really required
in the public key.

The key eg. returned by the Autocrypt bot contains the following
packets (from https://tools.ietf.org/html/rfc4880)

Public-key Packet -- 272 bytes raw
User ID Packet --  28 bytes raw, contains `bot123 <bot at autocrypt.org>`
Signature packet -- 343 byte raw
.... more packets

All in all about 3,7 KB of data. I'm no expert, but for the pure
encryption, only the first packet is required? What is expected by the
Autocrypt-standard.


On Thu, May 18, 2017 at 4:52 PM, Bjoern <b44treader at googlemail.com> wrote:
> Hi Daniel,
>
> I am no licensee-expert, but you are right, while netpgp uses a plain
> BSD license, the netpgp-et repository contains a LICENSE.txt pointing
> to the GPL - while there is an COPYRIGHT.txt saying that the original
> code uses the BSD license. Confusing.
>
> However, I've looked at too many libs and licenses the last weeks ;-)
> development of Delta Chat has stocked, I will just implement E2EE
> using netpgp/OpenSSL, maybe, if possible, I switch to netpgp-et later
> on, the API seems to be identical.
>
> Regarding GPGME: Yes, PGPME was a typo.
>
>
> On Thu, May 18, 2017 at 12:42 AM, Daniel Kahn Gillmor
> <dkg at fifthhorseman.net> wrote:
>> Hi Bjoern--
>>
>> On Wed 2017-05-17 22:39:17 +0200, Bjoern wrote:
>>> In fact, OpenSSL does not support PGP directly, but with a little bit
>>> of code around, it works, see http://www.netpgp.com/ from BSD -
>>> unfortunately, the project seems to be dead.
>>
>> My understanding is that P≡P is actually based on an updated version of
>> Net::PGP, which they've taken over as upstream.
>>
>> I'm offline right now, but my notes about it suggest that there's
>> supposed to be a mercurial repository at:
>>
>>   https://letsencrypt.pep.foundation/dev/repos/netpgp-et
>>
>> Again, there may be licensing issues with it.  Last time i looked, it
>> seemed like there was some sort of attempt to change it into GPL, which
>> afaik is incompatible with the OpenSSL license.  If you (or anyone from
>> P≡P who is reading this list!) knows of a nice resolution to the
>> licensing issue, please share it here.  it'd be great to have more
>> free-software C implementations of OpenPGP available.
>>
>>> PEP is mainly based upon PGPME which is based upon GnuPG
>>
>> itym GpgME, not PGPME.  is that right?  I agree that the architecture
>> for GpgME is much more complicated than a developer might prefer -- it's
>> mixed in with some underlying assumptions that GnuPG makes about what's
>> a reasonable way to use keys, and with the GnuPG underlying UI/API,
>> which can be complicated.
>>
>> having more C free software implementations available would be great.
>>
>>       --dkg