Add support for RSA, SHA-512, and Externally Hashed Payload Verification

[lock9]

Summary or problem description
We recently released the initial version of our Abstract Wallet for Neo (enclavewallet.com). One feature under consideration is social media login integration (OAuth-based logins). However, implementing it is currently blocked by missing cryptographic algorithms. Specifically, Neo is missing RSA and some hashing algorithms (like SHA512).

Our use case requires verifying signatures against externally hashed data rather than the original plaintext payload. Currently, the verification interops expect the entire original message, perform hashing internally, and then validate the signature. However, we cannot disclose the original JSON payload due to privacy constraints. We can only disclose the hash and associated signature, alongside a zero-knowledge proof indicating possession of the original payload.

Do you have any solution you want to propose?

• Enable verification of signatures against externally hashed payloads (applicable to all algorithms, not only RSA).
• Enable verification of RSA signatures.
• Add support for the SHA-512 hashing algorithm to facilitate interoperability with OAuth standards.

Where in the software does this update applies to?

• Compiler
• VM

EDIT: I don't know if these solutions will in fact, solve my problem. It seems that Using SHA512 inside ZK is extremely costly and may not be viable at all. However, I don't know/didn't find ZK-friendly hashing functions on Neo.

[Wi1l-B0t]

Do you want these features to be implemented as neo vm library(like CryptoLib)?

[roman-khimov]

One feature under consideration is social media login integration (OAuth-based logins). However, implementing it is currently blocked by missing cryptographic algorithms. Specifically, Neo is missing RSA and some hashing algorithms (like SHA512).

I'd like to see the scheme, OAuth is what's been talked about for quite some time in community. But my impression was that it doesn't require any additional crypto primitives. Requires a trusted third party (inevitably, can be distributed in somewhat similar to oracles way), but no more than that.

Still, extensions to crypto library can be done if really needed.

[lock9]

Do you want these features to be implemented as neo vm library(like CryptoLib)?

Yes, if possible. Being able to check RSA signatures will allow many new integrations. I hope it's possible to ingerate it (I know that key lengths will be a problem)

I'd like to see the scheme, OAuth is what's been talked about for quite some time in community. But my impression was that it doesn't require any additional crypto primitives.

The required cryptographic primitives depend on the platform provider. OAuth may not need them, but other authentication methods do.

We are exploring one use case, Discord. It is something like this:

• The user triggers a command.
• Discord sends a signed JSON payload using ed25519.
• The payload contains account verification data but also private user information that we can't share or store on-chain.
• We use a ZK circuit to prove that the payload contains the expected data without revealing it.
• Next, we prove that the message came from Discord, passing the payload hash and the signature.

So, if we:

• Prove that the JSON contains expected fields and values.
• Prove that the hash of the JSON is Z.
• Prove that Z was signed by Discord.

Then:

• We can confirm that the user owns the Discord account without revealing any private data.

However, SHA512 does not seem ZK-friendly (used in ed25519), and the proof verification cost would make this approach impractical, even if it's done just once.

Requires a trusted third party (inevitably, can be distributed in somewhat similar to oracles way), but no more than that.

That's true. You need a 'registered app' to support social logins, but it's not a big deal as long as this party can't make transactions on behalf of the user.