sbp commented on issue #214: URL: https://github.com/apache/tooling-trusted-releases/issues/214#issuecomment-3543801148
QuickLog2 belongs to a large family of audit log schemes that rely on a forward-resistant MAC. The first such scheme was, I believe, the Schneier-Kelsey one from 1998. QuickLog2 and its successor, Nitro, are optimised for high frequency logging in the Linux kernel. We can batch in the ATR, so our logging would be low frequency. Therefore, one of the other audit log schemes in the same family is likely to be more suitable. All of these schemes share the downside that the initial seed, _S_, must be stored on a trusted verifier server, _T_. There have been alternative schemes designed with asymmetric cryptography such as LogFAS, but they are typically unimplemented and, as in the case of LogFAS, catastrophic vulnerabilities were soon found. The idea of using Rekor in conjunction with a Schneier-Kelsey style scheme was that Rekor becomes a kind of surrogate _T_, but this sort of construction is unimplemented, and its security properties may be non-obvious, and non-trivial to study. This is exacerbated by the fact that Rekor itself allows a range of signature types. The Schneier-Kelsey scheme is quite simple at core, but we should try to identify an existing conservative and ideally audited implementation. We could in parallel try to find an asymmetric sealing scheme; there are a couple of potential candidates in the literature, but it is clear that this is a difficult domain. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
