ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2019-06-26 📝 Original message: Thank you for your ...
📅 Original date posted:2019-06-26
📝 Original message:
Thank you for your thought.
Another idea: would it be useful to split up large data (several megabytes long) and FEC-encode it in chunks (with each chunk having a separate MAC)?
That way even if some error occurs during transmission, it is possible to recover without re-downloading entire dataset.
Especially, since we need to decrypt first, before we can confirm the MAC: if the MAC fails for the chunk, it's better if we can use data from nearby chunks to recover, rather than download and re-decrypt again.
Or is this over-engineering?
Regards,
ZmnSCPxj
Sent with ProtonMail Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Wednesday, June 26, 2019 1:41 PM, Stepan Snigirev <snigirev.stepan at gmail.com> wrote:
> Hi ZmnSCPxj,
>
> > Does this require Bob to attempt both positive and negative sign for the y-coordinate?
> > Alternately we can force Sally to always use a scalar such that generated point has a fixed sign (or some other property to derive the sign of the missing coordinate).
>
> The best would be if Sally uses the point with a fixed sign, then Bob doesn't need to try twice and can start decrypting data from stream (for example if it's a DRM key for a movie).
> Similar approach is used for R-encoding in Schnorr signatures, so we could use the same convention here.
>
> On Tue, Jun 25, 2019 at 10:18 PM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
>
> > Good morning Stepan, and Nadav,
> >
> > Both additions seem good idea to me.
> >
> > > - Sally generates the invoice with the preimage `S` (i.e. x-coordinate of this point to make it 32-bytes long)
> >
> > Does this require Bob to attempt both positive and negative sign for the y-coordinate?
> > Alternately we can force Sally to always use a scalar such that generated point has a fixed sign (or some other property to derive the sign of the missing coordinate).
> >
> > Regards,
> > ZmnSCPxj
📝 Original message:
Thank you for your thought.
Another idea: would it be useful to split up large data (several megabytes long) and FEC-encode it in chunks (with each chunk having a separate MAC)?
That way even if some error occurs during transmission, it is possible to recover without re-downloading entire dataset.
Especially, since we need to decrypt first, before we can confirm the MAC: if the MAC fails for the chunk, it's better if we can use data from nearby chunks to recover, rather than download and re-decrypt again.
Or is this over-engineering?
Regards,
ZmnSCPxj
Sent with ProtonMail Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Wednesday, June 26, 2019 1:41 PM, Stepan Snigirev <snigirev.stepan at gmail.com> wrote:
> Hi ZmnSCPxj,
>
> > Does this require Bob to attempt both positive and negative sign for the y-coordinate?
> > Alternately we can force Sally to always use a scalar such that generated point has a fixed sign (or some other property to derive the sign of the missing coordinate).
>
> The best would be if Sally uses the point with a fixed sign, then Bob doesn't need to try twice and can start decrypting data from stream (for example if it's a DRM key for a movie).
> Similar approach is used for R-encoding in Schnorr signatures, so we could use the same convention here.
>
> On Tue, Jun 25, 2019 at 10:18 PM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
>
> > Good morning Stepan, and Nadav,
> >
> > Both additions seem good idea to me.
> >
> > > - Sally generates the invoice with the preimage `S` (i.e. x-coordinate of this point to make it 32-bytes long)
> >
> > Does this require Bob to attempt both positive and negative sign for the y-coordinate?
> > Alternately we can force Sally to always use a scalar such that generated point has a fixed sign (or some other property to derive the sign of the missing coordinate).
> >
> > Regards,
> > ZmnSCPxj