4 ms·

So should they have opted for an inexistent implementation of FourQ in Go so they don't have to roll their own (keeping in mind this is a library for experiment

So should they have opted for an inexistent implementation of FourQ in Go so they don't have to roll their own (keeping in mind this is a library for experimental deployment of PQ and ECC)?

rdtsc 1y ago
They should have found someone who knows what they are doing or not implement it at all. We're talking about a company with a $1B+ yearly revenue here. They put their name behind it https://blog.cloudflare.com/introducing-circl/ https://blog.cloudflare.com/introducing-circl/ and it looks like whoever they hired to do the work couldn't even read the wikipedia page for the algorithm.
- wbl 1y ago
  Both Kris and Armando have PhDs in cryptography. The issues here are a lot more subtle than that wiki article makes it seem.
  - rdtsc 1y ago
    > Both Kris and Armando have PhDs in cryptography. The issues here are a lot more subtle than that wiki article makes it seem. That's sort of make it look worse then, doesn't it? The main issue isn't that subtle. Even the wikipedia mentions it: > points should always be validated before being relied upon for any computation. Moreover the paper https://eprint.iacr.org/2015/565.pdf https://eprint.iacr.org/2015/565.pdf also mentions a few times: > Algorithm 2 assumes that the input point P is in E(Fp2)[N], i.e., has been validated according to Appendix A Appendix A: > The main scalar multiplication routine (in Algorithm 2) assumes that the input point lies in E(Fp2 )[N]. However, since we have #E(Fp2) = 392 · N, and in light of small subgroup attacks [39] that can be carried out in certain scenarios, here we briefly mention how our software enables the assertion...
    - commandersaki 1y ago
      You realise experts at cryptography, even implementation, are fallible right? Case in point: https://www.daemonology.net/blog/2011-01-18-tarsnap-critical-security-bug.html https://www.daemonology.net/blog/2011-01-18-tarsnap-critical... Not saying the same situation either; obviously Colin made a silly mistake while refactoring. We don't actually know the issue with these implementors, but again I ask, with having actual professionals in the field, what should they have done instead of rolling their own for a primitive that doesn't exist in the language?

So should they have opted for an inexistent implementation of FourQ in Go so they don't have to roll their own (keeping in mind this is a library for experimental deployment of PQ and ECC)?

rdtsc 1y ago

They should have found someone who knows what they are doing or not implement it at all. We're talking about a company with a $1B+ yearly revenue here. They put their name behind it https://blog.cloudflare.com/introducing-circl/ https://blog.cloudflare.com/introducing-circl/ and it looks like whoever they hired to do the work couldn't even read the wikipedia page for the algorithm.

wbl 1y ago
Both Kris and Armando have PhDs in cryptography. The issues here are a lot more subtle than that wiki article makes it seem.
- rdtsc 1y ago
  > Both Kris and Armando have PhDs in cryptography. The issues here are a lot more subtle than that wiki article makes it seem. That's sort of make it look worse then, doesn't it? The main issue isn't that subtle. Even the wikipedia mentions it: > points should always be validated before being relied upon for any computation. Moreover the paper https://eprint.iacr.org/2015/565.pdf https://eprint.iacr.org/2015/565.pdf also mentions a few times: > Algorithm 2 assumes that the input point P is in E(Fp2)[N], i.e., has been validated according to Appendix A Appendix A: > The main scalar multiplication routine (in Algorithm 2) assumes that the input point lies in E(Fp2 )[N]. However, since we have #E(Fp2) = 392 · N, and in light of small subgroup attacks [39] that can be carried out in certain scenarios, here we briefly mention how our software enables the assertion...
  - commandersaki 1y ago
    You realise experts at cryptography, even implementation, are fallible right? Case in point: https://www.daemonology.net/blog/2011-01-18-tarsnap-critical-security-bug.html https://www.daemonology.net/blog/2011-01-18-tarsnap-critical... Not saying the same situation either; obviously Colin made a silly mistake while refactoring. We don't actually know the issue with these implementors, but again I ask, with having actual professionals in the field, what should they have done instead of rolling their own for a primitive that doesn't exist in the language?