Re: Addition to EGO keys

[Schanzenbach, Martin]

Hi,

> On 5. Nov 2020, at 14:29, TheJackiMonster <thejackimonster@gmail.com> wrote:
> 
> Hi,
> 
> the newest changes of the identity service handling EGO keys allowed
> two different types of keypairs which makes it somewhat more difficult
> to interact with them.
> 
> So I would propose following functions to be added:
> 
> ssize_t GNUNET_IDENTITY_read_key_from_buffer(struct
> GNUNET_IDENTITY_PublicKey *key, const void* buffer)
> 
> ssize_t GNUNET_IDENTITY_write_key_to_buffer(const struct
> GNUNET_IDENTITY_PublicKey *key, void* buffer)

Is there anything wrong with GNUNET_GNSRECORD_identity_from_data
and GNUNET_GNSRECORD_data_from_identity ?

The "struct GNUNET_IDENTITY_PublicKey" is already a serializ(ed/able) data
structure. So there is not really a need to have those functions.
If you have a buffer, it must be sizeof (struct GNUNET_IDENTITY_PublicKey) to 
hold
a public key. Anything less/more is probably faulty data.

Of course, you could propose to simply move the GNSRECORD functions to identity.
The reason why it is in GNSRECORD, is because the "short" serialization which 
depends on the
key length is actually only required by GNS (records).

> 
> // both would depend on GNUNET_IDENTITY_key_get_length(...) which
> currently exists
> 
> int GNUNET_IDENTITY_public_key_verify(uint32_t purpose, const struct
> GNUNET_CRYPTO_EccSignaturePurpose *validate, const struct
> GNUNET_IDENTITY_Signature *sig, const struct GNUNET_IDENTITY_PublicKey
> *pub)
> 
> int GNUNET_IDENTITY_private_key_sign(const struct
> GNUNET_IDENTITY_PrivateKey *priv, const struct
> GNUNET_CRYPTO_EccSignaturePurpose *purpose, struct
> GNUNET_IDENTITY_Signature *sig)
> 
> // and GNUNET_IDENTITY_Signature would look like following:
> 
> struct GNUNET_IDENTITY_Signature {
>  uint32_t type;
>  union {
>    struct GNUNET_CRYPTO_EcdsaSignature ecdsa_signature;
>    struct GNUNET_CRYPTO_EddsaSignature eddsa_signature;
>  }
> }

Yes, this is something I omitted because you will have to change a lot of code
to make this consistent. And you will have the same serialization issue as
signature sizes may vary.
In most cases, you do not want the signature to be a union but as short as 
possible.
Which means find all occurrences in the GNUnet code that uses signatures and use
apply serialization function.

> 
> At least similar changes would ease the use of EGOs for
> authentification which will be used for example in the messenger
> service. I am also open for ideas to handle it differently. Maybe there
> is planned something else with EGOs or how authentification should be
> handled? Otherwise I would open a commit to add those functions which
> would pretty much check for the type of public/private key and use
> existing functions from GNUnet.

You can try, but make sure tests still pass for all components :)

> 
> I also wanted to ask how I could use the EGO keys for encryption of
> private messages. I know the functionality for signatures and
> verification but I would like to use them for encryption.

You do not use the EC key directly as you would for RSA.
Instead, you should use ECDHE. Say you want to encrypt for "Bob":

- Get the public key P_Bob from Bob
- Generate an ephemeral ECDH key pair P_ecdh, K_ecdh
- Calculate k = ECDH(P_Bob, K_ecdh)
- Use k to symmetrically encrypt message M: C = AES(k, M)
- Send (P_ecdh,C) to Bob
- Bob calculates k = ECDH(K_Bob, P_ecdh)
- Bob decrypts M = AES(k, C)

> 
> If there is a systematic reason to not use EGO keys for that purpose,
> how would I use asymmetric encryption with GNUnet then? I assume I
> would use libsodium directly otherwise?
> 

You can encapsulate the encryption for EGOs, of course, just like signatures as 
you proposed.

BR
Martin

> Happy Hacking
> Jacki

signature.asc
Description: Message signed with OpenPGP