Cryptography designs #869

otherview · 2022-11-23T10:30:17Z

Why is this change needed?

What changes were made as part of this PR:

Added designs in these sections

🚨 Definition of done 🚨

Unit tests added to cover new or changed functionality
Docs pages updated to cover new or changed functionality
Changelog.md updated

tudor-malene

If I were to write this design doc I would structure it a bit differently.
To make sure we go from the big picture to the details without anything major slipping through the cracks.

------ Proposed structure------

Obscuro Cryptography

Privacy in Obscuro is achieved by:

using local databases that run inside TEEs and write only encrypted data to disk
the ledger (list of user transactions) is stored encrypted as rollups in Ethereum
users submitting transactions encrypted with a well known key (the Obscuro Key)

The first element can be achieved by using existing solutions like edgelessDB.

To minimise the complexity for the second and third, we propose to start with a securely generated piece of entropy called: "The Master Seed"(MS),
and then use that to deterministically derive the keys necessary to achieve the other goals.

An additional complexity is that Obscuo has the requirement to support temporary privacy, and reveal transactions after a period of time has elapsed.

Scope

I. Generating the Master seed
II. Derive the Obscuro Key
III. Encrypting transactions such that they can be revealed

I. Generating the Master seed

use the random number generation available inisde the TEEs

II. Derive the Obscuro Key

The Obscuro Key is a Key-Pair, where the public key will be published to the Management contract, and used by all obscuro tooling ( like the wallet extension ) to encrypt transactions
Q: How to deterministically generate it based on the master seed. It should be the same on all enclaves.

III. Encrypting transactions such that they can be revealed

Requirements for revelation

The revelation period must be controlled by the smart contract develope who can choose between some predefined levels (how?)
After that period of time the transaction must be visible. (This can be achieved by either revealing the key or by revealing the transaction itself.)

An alternative revelation mechanism is for the actual state of the smart contracts to be revealed instead of the transactions.

Requirements for encrypting the transactions

The encrypted tx blob is written as calldata to the L1, which means the size of the cypher-text must be minimised

Note: we decide to reveal the key of encryption of the transactions because it allows for a simpler interactin with enclaves, and moving as much logic as possible into outside tooling.

Problems

Symmetric vs Asymentric encryption for rollup tx encryption

symmetric is more space efficient?
pick and algo (AES), and key size (128)?

How does a developer specify the reveal period?

view function with predefined name in the smart contract code. How do you ensure that it's not using random numbers or soemthing confusing? Does it matter?

Ensure a node operator can't fast forward the clock.

this means the internal time can't be used
it's possible to use hash chains, but it's complicated
best is to use ethereum blocks, but we need a decent way (maybe phase 2) to verify that ethereum blocks are from the canonical branch. Find a way o leverage the PoS protocol. (We'll need this mechanism anyway for governance decisions)

design/cryptography.md

design/rollup_encryption.md

otherview · 2022-11-24T14:10:27Z

If I were to write this design doc I would structure it a bit differently. To make sure we go from the big picture to the details without anything major slipping through the cracks.

------ Proposed structure------

Obscuro Cryptography

Privacy in Obscuro is achieved by:

using local databases that run inside TEEs and write only encrypted data to disk

the ledger (list of user transactions) is stored encrypted as rollups in Ethereum

users submitting transactions encrypted with a well known key (the Obscuro Key)

The first element can be achieved by using existing solutions like edgelessDB.

To minimise the complexity for the second and third, we propose to start with a securely generated piece of entropy called: "The Master Seed"(MS), and then use that to deterministically derive the keys necessary to achieve the other goals.

An additional complexity is that Obscuo has the requirement to support temporary privacy, and reveal transactions after a period of time has elapsed.

Scope

I. Generating the Master seed II. Derive the Obscuro Key III. Encrypting transactions such that they can be revealed

I. Generating the Master seed

use the random number generation available inisde the TEEs

II. Derive the Obscuro Key

The Obscuro Key is a Key-Pair, where the public key will be published to the Management contract, and used by all obscuro tooling ( like the wallet extension ) to encrypt transactions

Q: How to deterministically generate it based on the master seed. It should be the same on all enclaves.

III. Encrypting transactions such that they can be revealed

Requirements for revelation

The revelation period must be controlled by the smart contract develope who can choose between some predefined levels (how?)

After that period of time the transaction must be visible. (This can be achieved by either revealing the key or by revealing the transaction itself.)

An alternative revelation mechanism is for the actual state of the smart contracts to be revealed instead of the transactions.

Requirements for encrypting the transactions

The encrypted tx blob is written as calldata to the L1, which means the size of the cypher-text must be minimised

Note: we decide to reveal the key of encryption of the transactions because it allows for a simpler interactin with enclaves, and moving as much logic as possible into outside tooling.

Problems

Symmetric vs Asymentric encryption for rollup tx encryption

symmetric is more space efficient?

pick and algo (AES), and key size (128)?

How does a developer specify the reveal period?

view function with predefined name in the smart contract code. How do you ensure that it's not using random numbers or soemthing confusing? Does it matter?

Ensure a node operator can't fast forward the clock.

this means the internal time can't be used

it's possible to use hash chains, but it's complicated

best is to use ethereum blocks, but we need a decent way (maybe phase 2) to verify that ethereum blocks are from the canonical branch. Find a way o leverage the PoS protocol. (We'll need this mechanism anyway for governance decisions)

Cool I'll update the structure

integration/ethereummock/node.go

design/cryptography.md

tudor-malene · 2022-11-24T16:51:13Z

design/cryptography.md

+## 2. Derive the Obscuro Key
+- 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 


Sorry, what do you mean ?

design/cryptography.md

tudor-malene · 2022-11-24T17:04:52Z

design/cryptography.md

+        ]
+    ]
+]
+```


if I understand correctly, you're proposing the "AccessList" to be used by a smart contract developer to specify the revelation period.

I see a couple of issues with that:

how will that be done in practice,since the standard ethereum tooling has no clue about the revelation? At what level will this be added in practice?

What if a tool builds a "create" transaction that uses the AccessList? How will that play with the revelation using it?

There's a few assumptions that aren't right. Hopefully, with the document review this becomes clearer.

The privacy/encryption is at the transaction level not the smart contract level.
The user issues a transaction and that transaction can call 1000 contracts but it's all encrypted for the defined transaction revelation period.

To avoid disruption to current web3 frameworks, this will reuse the Access List field with specific data.
Obscuro parses the Access List fields and encrypts with the corresponding Revelation key.

Hope that cleares up a bit things. To answer the questions:

how will that be done in practice,since the standard ethereum tooling has no clue about the revelation? At what level will this be added in practice?

Short example answer: User goes to Obscuro-Uniswap site, User requests a swap AND selects a Revelation Period of 1 year, Obscuro-Uniswap ethers framework creates the transaction AND adds [0x0..., [0x0..04]] in the Accesslist Field, bla bla, Obscuro enclave unpacks the transaction, checks the AccessList field, sees Null Address + Revelation Period 4 and encrypts the transaction with the 1 year encryption revelation key.

What if a tool builds a "create" transaction that uses the AccessList? How will that play with the revelation using it?

Good q. The AccessList is a list of addresses, we're just appending one entry with the null address.

So if the a transaction with really specific AccessList items is created AND it requires a 1 month revelation period, it would just append that info to the list.

design/cryptography.md

tudor-malene · 2022-11-25T09:57:09Z

design/cryptography.md

+
+1. Symmetric vs Asymmetric encryption for rollup tx encryption.
+- symmetric is more space efficient
+- AES 256 is the battle tested standard


why not a 128bit key?

No particular reason as I didn't dig into the key size. I think that should be done in the testing/performance phase ?

Do you think we should use 128bit key ?

design/cryptography.md

tudor-malene · 2022-11-29T13:38:42Z

design/cryptography.md

+- Obscuro Key and Client (Viewing Key) are both asymmetric key pairs
+  - The Private Obscuro Key is deterministically calculated from Master Seed + Genesis Rollup
+  - The Private Client Key is created by the client in any way it chooses
+  - Both the Public keys of Obscuro and Client are derived, via a one way function, from their corresponding Private keys


I don't think this statement makes sense

I wanted to make explicit the path to obtaining the Public keys.
Without that sentence it's implicitly expected that the reader understands that Public keys are derived from Private keys.

Should I remove it, or is there a rephrasing that would make more sense ? WDYT ?

design/cryptography.md

tudor-malene · 2022-11-29T13:42:34Z

design/cryptography.md

-  - Given the key and the input the new key' is deterministically calculated/derived
+  - The new key' does not release any information pertaining the old key (one way function)
+  - Given the same key and the same input, the new key' is deterministically calculated/derived
+- Key derivation allows to segregate vulnerability impact. If one key is compromised, other keys, including the original key are not affected


which vulnerability?

If one key is compromised. Does that not make sense ? 🤔

design/cryptography.md

tudor-malene · 2022-11-29T13:45:30Z

design/cryptography.md

@@ -54,6 +55,23 @@ An additional complexity is that Obscuro has the requirement to support temporar
  - Transactions without Revelation Period specified are encrypted by default using the smallest unit of time revelation period


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

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.

tudor-malene · 2022-11-29T13:45:58Z

design/cryptography.md

+    * M - 1 day (24 * 3600/12 = 7200 blocks)
+    * L - 1 month (30 * 24 * 3600/12 = 216000 blocks)
+    * XL - 1 year (12 * 30 * 24 * 3600/12 = 2592000 blocks)
+- Central Sequencer stores the rollup revelation keys in a database with the corresponding decrypt time.


what are the requirements?

The requirements in the white paper are l1 blocks as the clock, the 5 revelation periods, and the key independent release. These are described in the section.

Maybe I can make them clearer. I've rewritten the section. But I'm not sure I understand if that's what you're asking.

otherview · 2023-07-17T13:58:22Z

Seems to be stale work - moving to a draft

otherview · 2023-07-17T13:59:58Z

Actually... should we close this work instead @tudor-malene ?

tudor-malene · 2023-12-19T11:59:53Z

@otherview , yes please. Let's close

otherview added 5 commits November 17, 2022 17:12

first commit

7585b47

pr comments

16b18bd

master seed

0b41686

Adding Cryptography design

4430d34

added tx revelation period design

2c004f2

tudor-malene reviewed Nov 24, 2022

View reviewed changes

pr comments

216ec47

using the new structure

65e6c68

tudor-malene reviewed Nov 25, 2022

View reviewed changes

otherview added 2 commits November 25, 2022 11:35

Merge branch 'main' into pedro/design_cryptography

aec1948

pr comments

02282b3

otherview requested a review from tudor-malene November 25, 2022 15:00

tudor-malene reviewed Nov 28, 2022

View reviewed changes

otherview added 4 commits November 28, 2022 15:17

Merge branch 'main' into pedro/design_cryptography

7ae6826

pr comments

ec59acc

pr comments

ebd4fbf

pr comments

2de63bb

tudor-malene reviewed Nov 29, 2022

View reviewed changes

pr comments

c4f232e

otherview marked this pull request as draft July 17, 2023 13:59

otherview closed this Dec 19, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Cryptography designs #869

Cryptography designs #869

otherview commented Nov 23, 2022

tudor-malene left a comment

otherview commented Nov 24, 2022

Obscuro Cryptography

Scope

I. Generating the Master seed

II. Derive the Obscuro Key

III. Encrypting transactions such that they can be revealed

Requirements for revelation

Requirements for encrypting the transactions

Problems

tudor-malene Nov 24, 2022

otherview Nov 25, 2022

tudor-malene Nov 24, 2022

otherview Nov 25, 2022

tudor-malene Nov 25, 2022

otherview Nov 25, 2022

tudor-malene Nov 29, 2022

otherview Nov 29, 2022

tudor-malene Nov 29, 2022

otherview Nov 29, 2022

tudor-malene Nov 29, 2022

otherview Nov 29, 2022 •

edited

Loading

tudor-malene Nov 29, 2022

otherview Nov 29, 2022

otherview commented Jul 17, 2023

otherview commented Jul 17, 2023

tudor-malene commented Dec 19, 2023

		@@ -54,6 +55,23 @@ An additional complexity is that Obscuro has the requirement to support temporar
		- Transactions without Revelation Period specified are encrypted by default using the smallest unit of time revelation period

Cryptography designs #869

Cryptography designs #869

Conversation

otherview commented Nov 23, 2022

Why is this change needed?

What changes were made as part of this PR:

🚨 Definition of done 🚨

tudor-malene left a comment

Choose a reason for hiding this comment

Obscuro Cryptography

Scope

I. Generating the Master seed

II. Derive the Obscuro Key

III. Encrypting transactions such that they can be revealed

Requirements for revelation

Requirements for encrypting the transactions

Problems

otherview commented Nov 24, 2022

Obscuro Cryptography

Scope

I. Generating the Master seed

II. Derive the Obscuro Key

III. Encrypting transactions such that they can be revealed

Requirements for revelation

Requirements for encrypting the transactions

Problems

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

otherview Nov 29, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

otherview commented Jul 17, 2023

otherview commented Jul 17, 2023

tudor-malene commented Dec 19, 2023

otherview Nov 29, 2022 •

edited

Loading