Re: [tcpm] public-private keys for TCP-AO

> On Oct 29, 2018, at 6:22 PM, Jakob Heitz (jheitz) <jheitz@cisco.com> wrote:
> 
> Can you think of a way to do it that will work?
> Like the KDF is just a static list or something.
> The sender generates a set of key pairs and numbers them.
> It then puts the list of public keys into a file and distributes them to all receivers in the clear.

You’d have to find a way to specify the use of private and public keys on both sides, in advance, and distribute enough for the upcoming connections - then you’d have to hash into that list in a way that avoids reuse. At that point, why not just distribute symmetric keys and be done with it?

Joe

> The KDF is just to index into this file.
>  
> Because the use case, at least, makes sense.
>  
> Regards,
> Jakob.
>  
> From: Joe Touch <touch@strayalpha.com> 
> Sent: Monday, October 29, 2018 6:13 PM
> To: Jakob Heitz (jheitz) <jheitz@cisco.com>
> Cc: tcpm@ietf.org
> Subject: Re: [tcpm] public-private keys for TCP-AO
>  
>  
> 
> 
> On Oct 29, 2018, at 5:45 PM, Jakob Heitz (jheitz) <jheitz@cisco.com <mailto:jheitz@cisco.com>> wrote:
>  
> Why was there not a public-private key algorithm specified for TCP-AO? Or did I miss it?
>  
> There has not been. I doubt it would make sense (see below).
> 
> 
> For example ECC.
> An MKT can specify a private key for the sender and a public key for the receivers.
>  
> Yes, but the MKT is derived into public/private keys using a KDF.
>  
> I am not aware of a KDF that can take a private key and generate a derived private key that would work with a correspondingly derived public key generated from the corresponding public key.
>  
> To use, the sender will hash the data, encrypt the hash and put the result into the MAC field.
> The receiver would decrypt the MAC field, then hash the data and verify the hash against the decrypted MAC.
> This way, the private key never needs to be exposed to anyone, simplifying key management.
> Is there any objection to getting this done?
>  
> See above; it doesn’t make sense with the way TCP-AO derives keys for each connection, AFAICT.
>  
> Joe
> 
> 
>  
> Regards,
> Jakob.
>  
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org <mailto:tcpm@ietf.org>
> https://www.ietf.org/mailman/listinfo/tcpm <https://www.ietf.org/mailman/listinfo/tcpm>
>  
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm