Threshold Key Derivation - Privacy on the IC

[ais]

Hey! The recording will be on youtube soon, we just need a moment to edit out all my bad jokes.

And indeed, happy to have a chat. Feel free to reach out at aisling.connolly@dfinity.org

[domwoe]

Just wanted to mention that we’ve some open bounties to get your hands on vetKeys:

Closed: BNT-8 - vetKeys - Enabling Privacy Preserving Applications on the IC

Hello hackers and bounty hunters, In time for the publication of the mock API for vetKeys and the associated community conversation, we’ll open a couple of bounties to get you acquainted with the API and its many applications before the actual implementation will be available on the IC. Interested? Please read on… Overview Status: Closed Project Type: Cooperative/Contest - Multiple workers can submit work, and the bounty is shared Time Commitment: Days Experience Level: Intermediate/Advanc…

[rabbithole]

@ais

The recording will be on youtube soon, we just need a moment to edit out all my bad jokes.

The time zone on my mac was different from what I am currently in, I was 3 hours late and have been constantly updating all resources since then in search of a video recording! I even prepared a question, but I failed, really looking forward to this video (with or without jokes)

@domwoe

we’ve some open bounties to get your hands on vetKeys

going to participate in multiple categories as it is part of my application anyway

[josephgranata]

I could not attend either, a customer meeting coincided with the meeting and I could not move it.

Looking forward to that video recording in YouTube!

[hokosugi]

Sorry if this is a silly question, but if it is possible to use any string as a crypto key, wouldn’t an attacker be able to find a key derived from the same string in a brute force attack and decrypt privacy data without permission?
I think Internet Identity is somewhat safe, but I’m worried about the protection of user name and password.

[Jupes_M]

@hokosugi

Sorry if this is a silly question, but if it is possible to use any string as a crypto key, you wouldn’t an attacker be able to find a key derived from the same string in a brute force attack and decrypt privacy data without permission?

Not a silly question at all. In fact, the overwhelming majorities of hacks are all socially engineered. Technologically, we can make things pretty much unhackable. It’s the human interface which usually fails. Or in the cryptocurrency world- rushing to market. Because- it’s not your hundreds of millions which was stolen, it was the ‘investors’.

I saw the vetKeys presentation, and even remember some of it. Besides having the string, your local key is also required to derive the new shared key.

@hokosugi

I think Internet Identity is somewhat safe, but I’m worried about the protection of user name and password.

There is only a principal identifiable with Internet Identity. Usernames and passwords are stored on the decentralized application’s canisters. The security risk here would be using the same credentials all the time, and one of the canisters gets compromised. But, without any way to know where you reused those credentials, an attacker would have to go hunt-and-pecking. And if it isn’t something which a script can be wrote for, they most likely won’t do it.

[Severin]

@hokosugi

wouldn’t an attacker be able to find a key derived from the same string in a brute force attack and decrypt privacy data without permission

No. In the background, when deriving the key form the string, the canister ID (or something similarly per-canister-unique thing) is also included to create the derivation source. So you can think of the derivation string being "<canister id><chosen string>". And if you do not have access to the canister there is no way you can produce the full derivation string

[ais]

Hi guys, the recording is now on YouTube: Community Conversation: vetKeys — Enabling Privacy Preserving Applications on the ICP - YouTube

In case you want to catch up, here’s the wall of links to the demos/bounties/etc for easy ref:

• vetKD system API proposal
• E2EE Demo Rust
• Encrypted Notes Demo using vetKD (Motoko+Rust)
• ic-vetkd-utils (vetKD user library)
• Original Encrypted Notes / vetKey Encrypted Notes diff
• Bounties Description
• Bounties Discussion
• Developer Documentation
• First Community Conversation
• Second Community Conversation
• Real World Crypto Presentation
• vetKeys paper
• vetKeys primer

[hokosugi]

One question.
One of the use cases is the MEV countermeasure,
Even if we send a TX with a time lock applied by vetKey to DeFi, won’t the miner extract it to the block while it is still encrypted?
If we take some action on the DeFi side, can we execute the TX?

[rabbithole]

I have implemented vetKeys in my application and now the files are stored in encrypted form. I also did file sharing and it works, I love this feature! I have a question about time-lock in I’m not entirely sure that I understand everything correctly. Should the time-lock be implemented by a standard time check before deriving the key to the user?

Suppose I want to make a file available for download after some time. I add an optional timelock field:

type SharedFile = {
    ...
    timelock : ?Time.Time;
};

and then before calling vetkd_public_key I check this field

switch (file.timelock) {
    case (?timelock) {
        if (Time.now() < timelock) return #err(#timelock);
    };
    case null {};
};

and don’t give the key to the user if the time hasn’t arrived. Or is there some other magic hidden here?

[Franko]

@ais I read through your proposal to add privacy to the Internet Computer (IC) by enabling canisters to perform threshold key derivation, and it sounds like a promising step towards enhancing confidentiality on the platform. if things all go as planned then this will empower dapps with encryption, threshold decryption, and signing capabilities, allowing for secure and private data handling. I’m looking forward to seeing how this will benefit users and developers alike.

–
@Franko

[NeutronStarPRO]

hi here is an article that may help you

VETKeys - Privacy on the IC

Hey everyone, we wrote an explainer article on VETKeys that introduces some of the concepts in an detailed and interesting way. My expertise is limited, and although I read the paper, I’m not 100% sure everything is fully accurate. So please take a look, and if there are any errors, kindly point them out so I can correct them. This article is from Constellation Book - if you find it helpful, feel free to drop a GitHub star! In the post, we aim to explain vetkeys and its use of threshold cryptog…

[NeutronStarPRO]

Hi here is an article that may help you understand how it works.

VETKeys - Privacy on the IC

Hey everyone, we wrote an explainer article on VETKeys that introduces some of the concepts in an detailed and interesting way. My expertise is limited, and although I read the paper, I’m not 100% sure everything is fully accurate. So please take a look, and if there are any errors, kindly point them out so I can correct them. This article is from Constellation Book - if you find it helpful, feel free to drop a GitHub star! In the post, we aim to explain vetkeys and its use of threshold cryptog…

[franzstefan]

@hokosugi

Even if we send a TX with a time lock applied by vetKey to DeFi, won’t the miner extract it to the block while it is still encrypted?

@hokosugi, I’m not sure what exactly you mean with “won’t the miner extract it to the block while it is still encrypted”, but the main idea for MEV protection with vetKD on, for example, a decentralized exchange (DEX) is that the DEX commits to the order of transactions for a particular time-slot while the transactions are still encrypted, and only after the time-slot has passed and no more transactions are accepted for that time-slot, the vetKD decryption key is derived and the transactions are decrypted and executed in the pre-determined order. And the Internet Computer Protocol will also make sure that no individual node (which, I believe is what you call “miner”) participating in a subnet can derive the decryption key by itself, that is, alone. Said differently, the decryption key can only be derived if the majority of the nodes agree to do so.

For more details on MEV protection, see, for example

• the paragraph on “Secret-bid auctions and MEV protection” in Section 1.3 Applications in the vetKeys paper
• the part on Front-running prevention in the first community conversation

[franzstefan]

@rabbithole, when we speak of time-lock, we usually mean time-lock encryption. The underlying idea is that a message can be encrypted “to the future”, meaning it can be decrypted at a specific time (in the future), but not earlier than that.

As it is also described in the vetKD paper (in Section 1.3), time-lock encryption can be achieved with vetKD, for example, via identity-based encryption (IBE) by letting a canister smart contract (aka dapp) return an IBE decryption key corresponding to a particular time(-slot), only if the respective time(-slot) is reached (or in the past), and by letting some sender IBE-encrypt a message (or file, etc.) using the desired earliest decryption time(-slot) as identity (that is, as derivation ID).

Does that make sense?

[hokosugi]

I was assuming that vetKey non-supported DeFi. For example, my intention is that if I throw a TX encrypted with vetKey to uniswap, it will not be processed by mempool with the TX still encrypted.
Reading the paper, it seems that DeFi is processed by decrypting it all at once using random beacons, so it would be difficult for other chains like uniswap. Am I wrong?

Also, the paper mentions “Blockchain-issued signatures and cross-chain bridges”, I understood that vetKey can be used for verification instead of the light client and that cross-chaining is possible at the user level. Will it be available like “Cex-like DeFi”?

[Severin]

@rabbithole

Suppose I want to make a file available for download after some time. I add an optional timelock field:

type SharedFile = {
    ...
    timelock : ?Time.Time;
};

and then before calling vetkd_public_key I check this field

switch (file.timelock) {
    case (?timelock) {
        if (Time.now() < timelock) return #err(#timelock);
    };
    case null {};
};

and don’t give the key to the user if the time hasn’t arrived. Or is there some other magic hidden here?

I had the same question and yes, this is the way to do this. No other magic. And AFAIK there is also no other way to do this - cryptography can’t access time

[rabbithole]

@Severin

And AFAIK there is also no other way to do this - cryptography can’t access time

as I understood from the answer above, time-lock is done by creating a derivation_id based on the time. But I don’t think that we can get the same encryption key if the time condition is met, because the derivation_id will be unique on each call.

let lockUtil = Time.now() + 60_000_000_000; // in 1 minute
derivation_id : Blob = Text.encodeUtf8(Nat.toText(lockUtil));

[Severin]

That matches my understanding. But the canister can always en/decrypt for arbitrary derivation ids, no matter what the system time says. If the canister only hands out the keys if the time is right, then you have the time-locked access control. But what I meant is that nothing stops a malicious canister from handing out the keys too early since it can always generate the string/derivation id for a future timestamp