The issue isn't how long the report can survive, the issue is whether an attacker can forge arbitrary reports. The situation as it stands, as far as I know, is:
ECDSA: may allow attackers to forge arbitrary reports in the future. Small code-size implementations have side channels. HSS-LMS: Stateful key Falcon: First implementation had side-channel. Newer implementations may not. (https://eprint.iacr.org/2019/893) I don't think it's reasonable to discount Falcon as a possible reporting signature just yet. I'm not saying we should claim that as a model use case; code signing is far more compelling. I'm just suggesting that we should keep an eye on developments since Falcon appears to make a lot of sense in constrained networks and devices. Brendan On Thu, Jul 25, 2024 at 5:33 PM Michael Richardson <[email protected]> wrote: > > > Brendan Moran <[email protected]> wrote: > > That said, I think it’s an open question whether HSS-LMS or Falcon is > > more appropriate for a constrained device signing reports in response > > to firmware loading. HSS-LMS has a fixed number of reports and a > > strategy key, while Falcon may have a timing side-channel, depending on > > implementation. > > Are the signed reports required to survive on their own over a CRQC? > > If not, if they are essentially signed and then transmitted upstream where > they might be added to an append-only log, then the signature from the device > neededn't survive very long. > > I think that the reports could be signed by the firmware updateble > application code, and so could be adapted from EcDSA to EdDSA to SPHINX+ to > SuperFalcon2050 as time goes by. > > _______________________________________________ > COSE mailing list -- [email protected] > To unsubscribe send an email to [email protected] _______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
