12 comments

[ 4.3 ms ] story [ 26.9 ms ] thread
And the relationship to Mojo programming language is?
This could be:

Great for security - Being able to safely compute secrets is a very difficult problem.

Fucking awful for security - More OEM secret controls and "analytics" that devolve into backdoors after someone yet again post keys online.

I created Mojo-V.

There's no back doors, but there's no integrity checking either, so a Mojo-V voting machine could take an encrypted vote and throw it away and add +1 to the attacker's favorite candidate.

A computational integrity checking mechanism will appear soon that will add a concise proof to every encrypted Mojo-V value, that will prove to the data owner that their requested computation was faithfully performed. And the mechanism also supports safe disclosures, too.

This should give data owners strong controls over what can be done with their data

By backdoor, I meant the capability to implement one.

The OEM looking for greater controls on their platform, would be considered the "data owner", here.

There's no real way to prevent that.

RISC-V is inevitable.
Was it really wise to name this Mojo when Chris Lattner, former Head 9f Engineering at SiFive also called his well funded programming language Mojo?
After skimming through the documentation this seems like a nice solution, but I'm not sure if this is a problem we want to solve.

Consumers are finding out the issue with cloud computing when their heating system can't turn on because Cloudflare is down. A cheaper and more reliable solution is still on-premises computing.

Large social network and content platforms don't have any incentive to keep your data safe because they want to monitor and own everything.

Maybe this is for something like a government running a public service?

This should not (so much) be compared with Fully Homomorphic Encryption (FHE) but with a Trusted Execution Environment (TEE). It is a very elegant and minimal way to implement TEEs, but suffers from the same drawbacks: a data owner has to trust the service provider to publish the public keys of actual properly constructed Mojo-V hardware rather than arbitrary public keys or public keys of maliciously constructed Mojo-V hardware.

[1] https://en.wikipedia.org/wiki/Trusted_execution_environment

To be clear, it's not a TEE replacement but does address one of the most common use cases of TEEs
I created Mojo-V.

For me, I see Mojo-V more like FHE than a TEE, for three primary reasons: 1) Like FHE, the tech is applied to variables and computation that doesn't touch protected variables is not affected. TEEs protect processes. 2) Like FHE, Mojo-V lacks software, timing, and microarchitectural side channels. TEEs are riddled with side channels. 3) Like FHE, no trust is extended to software because it cannot see the data it is processing. TEEs require that clients trust that the attested software has their best interests in mind.

Public key signing is like SGX, the vendor signs the public to certify that it is from real Mojo-V hardware.

(comment deleted)
(comment deleted)