Jeremy Spilman [ARCHIVE] on Nostr: 📅 Original date posted:2014-01-18 📝 Original message:> On Fri, Jan 17, 2014 at ...
📅 Original date posted:2014-01-18
📝 Original message:> On Fri, Jan 17, 2014 at 8:55 PM, Alan Reiner <etotheipi at gmail.com> wrote:
>> Isn't there a much faster asymmetric scheme that we can use? I've heard people talk about ed25519, though I'm not sure it can be used for encryption.
>
> Doing ECDH with our curve is within a factor of ~2 of the fastest
> encryption available at this security level, AFAIK. And separate
> encryption would ~double the amount of data vs using the ephemeral key
> for derivation.
>
> Using another cryptosystem would mandate carry around additional code
> for a fast implementation of that cryptosystem, which wouldn't be
> fantastic.
>
> So I'm not sure much can be improved there.
In the case where payment is being sent only to Q1, and Q2 is for discovery only, perhaps we could use a 160-bit curve for d2/Q2 and e/P resulting in 20 byte vs 32 bytes in the OP_RETURN, and of course faster multiplication.
80-bits of security I assume still greatly exceeds the actual level of privacy you get with the overall solution, and since Q2 is never protecting actual funds...
But if it's a "real weakening" of the privacy then definitely not worth it, and even the added complexity of another curve seems possibly not worth it...
📝 Original message:> On Fri, Jan 17, 2014 at 8:55 PM, Alan Reiner <etotheipi at gmail.com> wrote:
>> Isn't there a much faster asymmetric scheme that we can use? I've heard people talk about ed25519, though I'm not sure it can be used for encryption.
>
> Doing ECDH with our curve is within a factor of ~2 of the fastest
> encryption available at this security level, AFAIK. And separate
> encryption would ~double the amount of data vs using the ephemeral key
> for derivation.
>
> Using another cryptosystem would mandate carry around additional code
> for a fast implementation of that cryptosystem, which wouldn't be
> fantastic.
>
> So I'm not sure much can be improved there.
In the case where payment is being sent only to Q1, and Q2 is for discovery only, perhaps we could use a 160-bit curve for d2/Q2 and e/P resulting in 20 byte vs 32 bytes in the OP_RETURN, and of course faster multiplication.
80-bits of security I assume still greatly exceeds the actual level of privacy you get with the overall solution, and since Q2 is never protecting actual funds...
But if it's a "real weakening" of the privacy then definitely not worth it, and even the added complexity of another curve seems possibly not worth it...