I was scrolling back throuh the TUF Slack recently and found an interesting discussion[1][2] related to using compute-constrained hardware tokens (e.g. Yubikeys) for signing.
TL;DR The discussion pointed out that there was a limitation, both in terms of processing power and in terms of input bytes as to how much a Yubikey would accept, e.g. it was stated that on YubiHSM it was limited to the size of one message to the YubiHSM, i.e. 2019 bytes.
It could therefore perhaps be useful in this context to formally enable support in the specification for pre-hash modes of signing, e.g. Ed25519ph and others.
There are other hardware keys out there, e.g. Tilitis TKey which by definition can support any algorithm, including Ed25519ph, but you would still be limited to the processing-power and perhaps input size too.
[1] https://cloud-native.slack.com/archives/C8NMD3QJ3/p1719216361044959
[2] https://cloud-native.slack.com/archives/C8NMD3QJ3/p1719229551933119
I was scrolling back throuh the TUF Slack recently and found an interesting discussion[1][2] related to using compute-constrained hardware tokens (e.g. Yubikeys) for signing.
TL;DR The discussion pointed out that there was a limitation, both in terms of processing power and in terms of input bytes as to how much a Yubikey would accept, e.g. it was stated that on YubiHSM it was limited to the size of one message to the YubiHSM, i.e. 2019 bytes.
It could therefore perhaps be useful in this context to formally enable support in the specification for pre-hash modes of signing, e.g. Ed25519ph and others.
There are other hardware keys out there, e.g. Tilitis TKey which by definition can support any algorithm, including Ed25519ph, but you would still be limited to the processing-power and perhaps input size too.
[1] https://cloud-native.slack.com/archives/C8NMD3QJ3/p1719216361044959
[2] https://cloud-native.slack.com/archives/C8NMD3QJ3/p1719229551933119