Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cryptography designs #869

Closed
wants to merge 14 commits into from
Closed

Cryptography designs #869

Show file tree
Hide file tree
Changes from 2 commits
Commits
Show all changes
14 commits
Select commit Hold shift + click to select a range
7585b47
first commit
otherview Nov 17, 2022
16b18bd
pr comments
otherview Nov 18, 2022
0b41686
master seed
otherview Nov 18, 2022
4430d34
Adding Cryptography design
otherview Nov 23, 2022
2c004f2
added tx revelation period design
otherview Nov 24, 2022
216ec47
pr comments
otherview Nov 24, 2022
65e6c68
using the new structure
otherview Nov 24, 2022
aec1948
Merge branch 'main' into pedro/design_cryptography
otherview Nov 25, 2022
02282b3
pr comments
otherview Nov 25, 2022
7ae6826
Merge branch 'main' into pedro/design_cryptography
otherview Nov 28, 2022
ec59acc
pr comments
otherview Nov 28, 2022
ebd4fbf
pr comments
otherview Nov 28, 2022
2de63bb
pr comments
otherview Nov 29, 2022
c4f232e
pr comments
otherview Nov 29, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
50 changes: 32 additions & 18 deletions design/cryptography.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -17,32 +17,47 @@ An additional complexity is that Obscuro has the requirement to support temporar

## Scope

1. Generating the Master seed
2. Derive the Obscuro Key
3. Encrypting transactions such that they can be revealed
1. Master Seed Generation
2. Enclave Encrypted Communication
3. Transaction Encryption per Rollup with Revelation Period
4. Reveal the rollup transactions

## 1. Generating the Master seed
## 1. Master Seed Generation
- Master Seed is a strongly generated entropy data that serves as the encryption base of the network
- Use the random number generation available inside the TEEs
- Generation happens when the central sequencer bootstraps the network
otherview marked this conversation as resolved.
Show resolved Hide resolved
- The central sequencer generates the Master seed and initializes the Management Contract
- Upon successful attestation the Central Sequencer uses the attested enclave public key to share the Master Seed
otherview marked this conversation as resolved.
Show resolved Hide resolved


## 2. Derive the Obscuro Key
## 2. Ensure Enclave Encrypted Communication
- Client-Enclave communication is encrypted using the Obscuro Key
- Clients encrypt using the Obscuro Key - Public Key
- Enclave responds encrypting with the Obscuro Key - Private Key
otherview marked this conversation as resolved.
Show resolved Hide resolved
- The Obscuro Key is a Key-Pair derived from the Master Seed + Genesis Rollup
- The Public key will be published to the Management contract and used by all obscuro tooling ( like the wallet extension ) to encrypt transactions
- The Private key will be determined by other enclaves by deriving the Master Seed + Genesis Rollup
- The Master Seed will be shared using the attestation process
- The Genesis Rollup will be shared when reading the L1 blocks
- The Private key will be only available inside the enclave through key derivation
- Enclaves will determine the Private key when deriving the Master Seed + Genesis Rollup
otherview marked this conversation as resolved.
Show resolved Hide resolved
- Enclaves have the Master Seed through the attestation process
- Enclaves fetch Genesis Rollup through the Layer 1 blocks
otherview marked this conversation as resolved.
Show resolved Hide resolved

- HKDF (HMAC-based Key Derivation Function) is used to derive keys
- Given the high entropy of the Master Seed no need for PBKDF Family key stretching
- Derivations use public rollup metadata such as height ( or some other shared field ) in the Info component of HKDF and use a fixed size salt as per https://soatok.blog/2021/11/17/understanding-hkdf/
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

which height?
Remember, this section is about generating an asymmetric key-pair from the master seed alone.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point - I think we're using the word derivation too loosely in this document.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

given that this is in the section about the communication with the enclave, the "derivation" should be explained in that context

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good spot. That wasn't right. I removed the derivation wording in the communication chapter.

Explained the derivation in the next chapter where it makes more sense though. WDYT ?



## 3. Encrypting transactions such that they can be revealed
- Transactions are encrypted by default using the smallest unit of time revelation period
- Transactions using AccessList can specify the desired revelation period
- Using Null Address combined with hexadecimal 1-5 level determines the revelation period
- Obscuro interprets the revelation period and encrypts the transaction with the corresponding revelation period key
## 3. Transaction Encryption per Rollup with Revelation Period
- Transactions are encrypted in Obscuro to provide confidentiality
otherview marked this conversation as resolved.
Show resolved Hide resolved
- To avoid base-key compromise, transaction encryption keys are derived twice
otherview marked this conversation as resolved.
Show resolved Hide resolved
- Each rollup has a Rollup Encryption Key derived from the Master Seed + Rollup
otherview marked this conversation as resolved.
Show resolved Hide resolved
- Each transaction is encrypted with a Revelation Period Key that is derived from the Rollup Encryption Key + Revelation Period
- HKDF (HMAC-based Key Derivation Function) is used to derive keys
- Given the high entropy of the Master Seed no need for PBKDF Family key stretching
- Derivations use public rollup metadata such as height ( or some other shared field ) in the Info component of HKDF and use a fixed size salt as per https://soatok.blog/2021/11/17/understanding-hkdf/
- EVM-Compatible Transactions using [AccessList](https://eips.ethereum.org/EIPS/eip-2930) property are able to specify the desired revelation period
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this needs further analysis.
How would a developer of a smart contract using standard ethereum tooling specify the revelation period for that contract?
How would a user know what the RP is?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm confused, what's a revelation period for a contract ?

These only specify transaction-based revelation periods. A transaction is issued and for a certain period, it's encrypted.
Do you mean contract creation transactions ? Like a dev creating a smart contract and the creation tx being encrypted for a RP ?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's why it's good to start by stating the requirements as clearly as possible.
in the WP: https://whitepaper.obscu.ro/obscuro-whitepaper/detailed-design.html#transaction-encryption

One of the explicit design goals of Obscuro is to help application developers achieve their privacy requirements while giving them the tooling to disincentivise their users from using the application for illegal behaviour such as money laundering.
When deploying a contract to Obscuro, the developer has to choose one of the predefined revealing options:

The requirement is that the dApp developers decide the revelation period for all transactions that call that contract.

This is not a concern of the end-user .

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All right I didn't read it like that. To be fair that isn't super explicit. I read it as the web3 dev creates a tx that is encrypted for X amount of time.

It seems like interacting with certain contracts encrypts the transaction for a certain amount of time ? Is that it ?

What's the design you have in mind ?

- Using `AccessList` Address _Null Address_ combined with Storage Key _hexadecimal 1-5_ determines the revelation period
- Transactions without Revelation Period specified are encrypted by default using the smallest unit of time revelation period
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is not correct.
Transactions don't have a revelation period as an intrinsic property of them.
It's only the smart contracts that have this property

Copy link
Contributor Author

@otherview otherview Nov 29, 2022 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That makes sense, it was not from the whitepaper, it was my proposal.

Where can I read about the expected revelation design ? I didn't see anything in regard to this on the white paper, but I might have missed it.



The [specification](https://eips.ethereum.org/EIPS/eip-2930) of the `AccessList` Field is as follows:

Expand Down Expand Up @@ -103,7 +118,6 @@ An example would be:
- Validators do not reveal keys so that keys are not susceptible to attacks
otherview marked this conversation as resolved.
Show resolved Hide resolved
- Central Sequencer stores the keys in a rollup, decrypt time, key tuple in a database.
otherview marked this conversation as resolved.
Show resolved Hide resolved
- When a Light Batch is created the revealed keys are appended to it and removed from the database.
otherview marked this conversation as resolved.
Show resolved Hide resolved
- If the database is lost for some reason, the Central Sequencer can recalculate the keys on-demand.


### Problems
Expand All @@ -120,8 +134,8 @@ An example would be:
- Validators do not release keys, only the centralized sequencer releases them

4. In the event of a db failure how does the central sequencer know which keys to recalculate
otherview marked this conversation as resolved.
Show resolved Hide resolved
- Traversing the existing chain might be too expensive
- Sequencer can provide and on-demand key reveal service
- Backed by enough horizontal scalability
- Providing the rollup height and revelation period any service can easily determine if the key is to be released
- Traversing the existing chain and recalculating keys might be too expensive
- Sequencer can reveal keys on-demand with recalculating the whole chain

5. Do validators have a validation period ? How can a validation period be enforced if they are given a non-mutable Master Seed ?
otherview marked this conversation as resolved.
Show resolved Hide resolved
6. Do validators need the Obscuro Private Key ?
1 change: 0 additions & 1 deletion integration/ethereummock/node.go
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -335,7 +335,6 @@ func (m *Node) startMining() {
m.logger.Info(" starting miner...")
// stores all transactions seen from the beginning of time.
mempool := make([]*types.Transaction, 0)
types.DynamicFeeTx{}
z := int32(0)
interrupt := &z

Expand Down