Comment by cryptonector | Hacker News Reader

Comment by cryptonector | Hacker News Reader

Parent Full thread

Yeah, but it would go a looong way to getting us (the public) to use Fil-C in production. Like I'd really like to be able to run OpenSSH using Fil-C and I really don't want to have to worry about the C-coded crypto being non-constant-time.

What I suggest as a medium-term solution might be to have macros that expand to nothing if Fil-C is not used but which expand to a Fil-C macro decoration that indicates that the author thinks the assembly (or assembly coded function) is Fil-C-safe.

Now... I know, there's more, right, like you burn a register to keep a pointer to the Fil-C thread data structure, and the assembly needs to not step on that, so ok, it's probably harder than I'm making it seem, but maybe not much harder because you can save that pointer as part of the exit and restore it as part of the enter.

I do trust that your crazy ideas are crazy but workable though!

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?

> 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.

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

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.

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?

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.

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 on news.ycombinator.com