6 ms·
> But I guess you really want the OpenSSL out-of-line assembly to work? Yes. And that code generally does not invoke the allocator or stray out of the bounds
by cryptonector 1y ago
> But I guess you really want the OpenSSL out-of-line assembly to work?
Yes. And that code generally does not invoke the allocator or stray out of the bounds of the given buffers, so at the very least you could mark that assembly as trusted for this mode.
- pizlonator 1y agoYeah, I'll have to come up with a decent way of allowing this, at some point. But see https://fil-c.org/runtime https://fil-c.org/runtime It's really about creating an FFI for Fil-C, because Fil-C has its own calling convention and symbol mangling. It could be a lot of work. And, worst case, it ends up being a footgun
- cryptonector 1y agoI'm sure for many people's $WORK the ability to run OpenSSH built with Fil-C and constant-time crypto would be amazing, and it would be great advertising for Fil-C. But there is no way any of us would run OpenSSH built with Fil-C in production w/o constant-time crypto.
- pizlonator 1y agoThat's good to know. If I made the assembly memory safe under Fil-C rules by running it through a transform that inserted additional instructions but did not otherwise change what was happening, would you trust that it's still constant-time?
- Vecr 1y agoYes. Don't branch on key or in-clear data. Otherwise, ok. If a user is doing onion wrapping, they don't want you to branch on the code data either.
- cryptonector 1y agoYou can reason about it, that if the instructions in question are not dependent on a key or plaintext value then it won't affect the constant time nature of the implementation of the cryptographic algorithm.