points
5 days ago
| 1 comment
| HN
That's a good point.

Note that statically checked inline asm is very achievable, so those folks who do constant time crypto by concealing their math operators behind inline asm will get what they need.

But I guess you really want the OpenSSL out-of-line assembly to work?

cryptonector
5 days 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.

reply
pizlonator
5 days ago
[-]
Yeah, I'll have to come up with a decent way of allowing this, at some point.

But see 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

reply
cryptonector
5 days ago
[-]
I'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.
reply
pizlonator
5 days ago
[-]
That'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?

reply
Vecr
5 days ago
[-]
Yes. 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.

reply
cryptonector
5 days ago
[-]
You 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.
reply