mirror of
https://github.com/vacp2p/rfc-index.git
synced 2026-01-11 00:28:13 -05:00
Compare commits
10 Commits
structural
...
nom-signin
| Author | SHA1 | Date | |
|---|---|---|---|
|
f4a778c305 | ||
|
|
c6aa2d1235 | ||
|
|
7922816a85 | ||
|
|
4510dee306 | ||
|
|
b28542e4c3 | ||
|
|
800c275533 | ||
|
|
b60abdb2ff | ||
|
|
5e3b4788ec | ||
|
|
36caaa621a | ||
|
|
db90adc94e |
134
nomos/raw/digital-signature.md
Normal file
134
nomos/raw/digital-signature.md
Normal file
@@ -0,0 +1,134 @@
|
||||
---
|
||||
title: NOMOS-DIGITAL-SIGNATURE
|
||||
name: Nomos Digital Signature
|
||||
status: raw
|
||||
editor:
|
||||
contributors:
|
||||
- Jimmy Debe <jimmy@status.im>
|
||||
-
|
||||
---
|
||||
|
||||
## Abstract
|
||||
|
||||
This specification describes the digital signature element,
|
||||
which is used for different components in the Nomos system design.
|
||||
Thoughout the system, each Nomos layer share the same signature scheme.
|
||||
|
||||
## Background
|
||||
|
||||
The Nomos Bedrock consist of a few key components that Nomos Network is built on,
|
||||
see the
|
||||
[Nomos whitepaper](https://nomos-tech.notion.site/The-Nomos-Whitepaper-1fd261aa09df81318690c6f398064efb?pvs=97#1fd261aa09df817bac4ad46fdb8d94ab)
|
||||
for more information.
|
||||
The Bedrock Mantle component serves as the operating system of Nomos.
|
||||
This includes facilitating operations like writing data to the blockchain or
|
||||
a restricted ledger of notes to support payments and staking.
|
||||
This component also defines how Nomos zones update their state and
|
||||
the coordination between the Nomos zone executor nodes.
|
||||
It is like a system call interface designed to provide a minimal set of operations
|
||||
to interact with lower-level Bedrock services.
|
||||
It is an execution layer that connects Nomos services
|
||||
to provide the necessary functionality for sovereign rollups and zones,
|
||||
see [Common Ledger specification](https://nomos-tech.notion.site/Common-Ledger-Specification-1fd261aa09df81088b76f39cbbe7c648) for more on Nomos zones.
|
||||
|
||||
In order for the Bedrock layer to remain lightweight, it focuses on data availability
|
||||
and verification rather than execution.
|
||||
Native zones on the other hand will be able to define their state transition function
|
||||
and prove to the Bedrock layer their correct execution.
|
||||
The Bedrock layer components share the same digital signature mechanism to ensure security and privacy.
|
||||
This document will describe the validation tools that are used with Bedrock services in the Nomos network.
|
||||
|
||||
## Wire Format
|
||||
|
||||
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”,
|
||||
“SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and
|
||||
“OPTIONAL” in this document are to be interpreted as described in [RFC2119](https://www.ietf.org/rfc/rfc2119.txt).
|
||||
|
||||
The signature schemes used by the provers and
|
||||
verifiers include:
|
||||
|
||||
- ZKSignature
|
||||
- EdDSA Digital Signature Algorithm
|
||||
|
||||
### EdDSA
|
||||
|
||||
EdDSA is a signature scheme based on elliptic-curve cryptography,
|
||||
defined over twisted [Edwards curves](https://eprint.iacr.org/2008/013.pdf).
|
||||
Nomos uses the Ed25519 instances uses Curve25519,
|
||||
providing 128-bit security for general purpose signing.
|
||||
EdDSA SHOULD NOT be used for ZK circuit contruction.
|
||||
|
||||
The prover computes the following EdDSA signature, twisted Edwards curve Curve25519:
|
||||
|
||||
$$ -x^2 + y^2 = 1 - (121665/121666)x^2y^2 \mod{(2^{255} - 19)} $$
|
||||
|
||||
- The public key size MUST be 32 bytes
|
||||
- The signature size MUST be 64 bytes.
|
||||
- The public key MUST NOT already exist
|
||||
|
||||
### ZKSignature
|
||||
|
||||
The ZkSignature scheme enables a prover to demonstrate cryptographic knowledge of a secret key,
|
||||
corresponding to a publicly available key,
|
||||
without revealing the secret key itself.
|
||||
The following is the structure for a proof attesting public key:
|
||||
|
||||
```python
|
||||
|
||||
class ZkSignaturePublic:
|
||||
public_keys: list[ZkPublicKey] # The public keys signing the message
|
||||
msg: hash # The hash of the message
|
||||
|
||||
```
|
||||
|
||||
The prover knows a witness:
|
||||
|
||||
```python
|
||||
|
||||
class ZkSignatureWitness:
|
||||
# The list of secret keys used to signed the message
|
||||
secret_keys: list[ZkSecretKey]
|
||||
|
||||
```
|
||||
|
||||
Such that the following constraints hold:
|
||||
|
||||
The number of secret keys is equal to the number of public keys:
|
||||
|
||||
```python
|
||||
|
||||
assert len(secret_keys) == len(public_keys)
|
||||
|
||||
```
|
||||
|
||||
Each public key is derived from the corresponding secret key.
|
||||
|
||||
```python
|
||||
|
||||
assert all(
|
||||
notes[i].public_key == hash("NOMOS_KDF", secret_keys[i])
|
||||
for i in range(len(public_keys)
|
||||
)
|
||||
|
||||
```
|
||||
|
||||
- The proof MUST be embedded in the hashed `msg`.
|
||||
|
||||
The ZkSignature circuit MUST take a maximum of 32 public keys as inputs.
|
||||
To prove ownership when lower than 32 keys,
|
||||
the remaining inputs MUST be padded with the public key corresponding
|
||||
to the secret key `0`.
|
||||
These padding are ignored during execution.
|
||||
The outputs of the circuit have no size limit,
|
||||
as they MUST be included in the hashed `msg`.
|
||||
|
||||
## Copyright
|
||||
|
||||
Copyright and related rights waived via
|
||||
[CC0](https://creativecommons.org/publicdomain/zero/1.0/).
|
||||
|
||||
## References
|
||||
|
||||
- [Nomos whitepaper](https://nomos-tech.notion.site/The-Nomos-Whitepaper-1fd261aa09df81318690c6f398064efb?pvs=97#1fd261aa09df817bac4ad46fdb8d94ab)
|
||||
- [Common Ledger specification](https://nomos-tech.notion.site/Common-Ledger-Specification-1fd261aa09df81088b76f39cbbe7c648)
|
||||
- [Edwards curves](https://eprint.iacr.org/2008/013.pdf)
|
||||
@@ -265,9 +265,13 @@ the following places could take advantage of a significantly smaller public key:
|
||||
|
||||
In the case of QR codes a compressed public key can reduce the complexity of the derived codes:
|
||||
|
||||
| Uncompressed | Compressed |
|
||||
| --- | --- |
|
||||
|||
|
||||
| Uncompressed |
|
||||
| --- |
|
||||
| |
|
||||
|
||||
| Compressed |
|
||||
| --- |
|
||||
| |
|
||||
|
||||
### Key Encoding
|
||||
|
||||
|
||||
@@ -422,7 +422,7 @@ Credentials MUST follow the specifications of section 5.3 of
|
||||
|
||||
Below follows the flow diagram for the generation of credentials.
|
||||
Users MUST generate key pairs by themselves.
|
||||
|
||||
|
||||
|
||||
### Message framing
|
||||
|
||||
@@ -765,10 +765,10 @@ CredentialType credential_types<V>;
|
||||
|
||||
The flow diagram shows the procedure to fetch key material from other
|
||||
users:
|
||||
|
||||
|
||||
|
||||
Below follows the flow diagram for the creation of a group:
|
||||
|
||||
|
||||
|
||||
### Group evolution
|
||||
|
||||
@@ -843,15 +843,15 @@ The client MUST apply the proposals in the list in the order described
|
||||
in Section 12.3 of [RFC9420](https://datatracker.ietf.org/docrfc9420/).
|
||||
|
||||
Below follows the flow diagram for the addition of a member to a group:
|
||||
|
||||
|
||||
|
||||
The diagram below shows the procedure to remove a group member:
|
||||
|
||||
|
||||
|
||||
|
||||
The flow diagram below shows an update procedure:
|
||||
|
||||
|
||||
|
||||
|
||||
### Commit messages
|
||||
|
||||
@@ -1293,7 +1293,7 @@ and checks that it corresponds to an address contained in the ACL.
|
||||
7. Off-chain - Alice sends a welcome message to Bob.
|
||||
8. Off-chain - Alice SHOULD broadcasts a message announcing the
|
||||
addition of Bob to other users of the group.
|
||||
|
||||
|
||||
|
||||
#### Alice does not know Bob’s Ethereum address
|
||||
|
||||
@@ -1316,7 +1316,7 @@ contract.
|
||||
8. Off-chain - Alice SHOULD broadcasts a message announcing the
|
||||
addition of Bob to other users of the group.
|
||||
|
||||
|
||||
|
||||
|
||||
### Considerations regarding smart contracts
|
||||
|
||||
@@ -1336,7 +1336,7 @@ off-chain message.
|
||||
- The creator of the contract MUST update the ACL, and send
|
||||
messages to the group for key update.
|
||||
|
||||
|
||||
|
||||
|
||||
> It is important to note that both
|
||||
user removal and updates of any kind
|
||||
|
||||
1501
vac/raw/mix.md
1501
vac/raw/mix.md
File diff suppressed because it is too large
Load Diff
@@ -7,11 +7,12 @@ category: Standards Track
|
||||
tags: waku-application
|
||||
editor: Aaryamann Challani <p1ge0nh8er@proton.me>
|
||||
contributors:
|
||||
- Andrea Piana <andreap@status.im>
|
||||
- Pedro Pombeiro <pedro@status.im>
|
||||
- Corey Petty <corey@status.im>
|
||||
- Oskar Thorén <oskarth@titanproxy.com>
|
||||
- Dean Eigenmann <dean@status.im>
|
||||
- Andrea Piana <andreap@status.im>
|
||||
- Pedro Pombeiro <pedro@status.im>
|
||||
- Corey Petty <corey@status.im>
|
||||
- Oskar Thorén <oskarth@titanproxy.com>
|
||||
- Dean Eigenmann <dean@status.im>
|
||||
- Filip Dimitrijevic <filip@status.im>
|
||||
---
|
||||
|
||||
## Abstract
|
||||
@@ -38,7 +39,7 @@ without other nodes network being able to read their messages.
|
||||
which provide assurances that session keys will not be compromised
|
||||
even if the private keys of the participants are compromised.
|
||||
Specifically, past messages cannot be decrypted by a third-party
|
||||
who manages to get a hold of a private key.
|
||||
who manages to obtain those private key.
|
||||
|
||||
- **Secret channel** describes a communication channel
|
||||
where a Double Ratchet algorithm is in use.
|
||||
@@ -73,7 +74,7 @@ The main cryptographic protocol is a Double Ratchet protocol,
|
||||
which is derived from the
|
||||
[Off-the-Record protocol](https://otr.cypherpunks.ca/Protocol-v3-4.1.1.html),
|
||||
using a different ratchet.
|
||||
[The Waku v2 protocol](../../core/10/waku2.md)
|
||||
[The Waku v2 protocol](/waku/standards/core/10/waku2.md)
|
||||
subsequently encrypts the message payload, using symmetric key encryption.
|
||||
Furthermore, the concept of prekeys
|
||||
(through the use of [X3DH](https://signal.org/docs/specifications/x3dh/))
|
||||
@@ -234,38 +235,41 @@ Where:
|
||||
([reference wire format](https://github.com/status-im/status-go/blob/a904d9325e76f18f54d59efc099b63293d3dcad3/services/shhext/chat/encryption.proto#L47))
|
||||
|
||||
```protobuf
|
||||
message X3DHHeader {
|
||||
// Alice's ephemeral key `EK_A`
|
||||
bytes key = 1;
|
||||
// Bob's bundle signed prekey
|
||||
bytes id = 4;
|
||||
}
|
||||
message X3DHHeader {
|
||||
// Alice's ephemeral key `EK_A`
|
||||
bytes key = 1;
|
||||
// Bob's bundle signed prekey
|
||||
bytes id = 4;
|
||||
}
|
||||
```
|
||||
|
||||
- `DR_header`: Double ratchet header ([reference wire format](https://github.com/status-im/status-go/blob/a904d9325e76f18f54d59efc099b63293d3dcad3/services/shhext/chat/encryption.proto#L31)).
|
||||
Used when Bob's public bundle is available:
|
||||
|
||||
``` protobuf
|
||||
message DRHeader {
|
||||
// Alice's current ratchet public key (as mentioned in [DR spec section 2.2](https://signal.org/docs/specifications/doubleratchet/#symmetric-key-ratchet))
|
||||
bytes key = 1;
|
||||
// number of the message in the sending chain
|
||||
uint32 n = 2;
|
||||
// length of the previous sending chain
|
||||
uint32 pn = 3;
|
||||
// Bob's bundle ID
|
||||
bytes id = 4;
|
||||
}
|
||||
message DRHeader {
|
||||
// Alice's current ratchet public key
|
||||
bytes key = 1;
|
||||
// number of the message in the sending chain
|
||||
uint32 n = 2;
|
||||
// length of the previous sending chain
|
||||
uint32 pn = 3;
|
||||
// Bob's bundle ID
|
||||
bytes id = 4;
|
||||
}
|
||||
```
|
||||
|
||||
Alice's current ratchet public key (above) is mentioned in
|
||||
[DR spec section 2.2](https://signal.org/docs/specifications/doubleratchet/#symmetric-key-ratchet)
|
||||
|
||||
- `DH_header`: Diffie-Hellman header (used when Bob's bundle is not available):
|
||||
([reference wire format](https://github.com/status-im/status-go/blob/a904d9325e76f18f54d59efc099b63293d3dcad3/services/shhext/chat/encryption.proto#L42))
|
||||
|
||||
``` protobuf
|
||||
message DHHeader {
|
||||
// Alice's compressed ephemeral public key.
|
||||
bytes key = 1;
|
||||
}
|
||||
message DHHeader {
|
||||
// Alice's compressed ephemeral public key.
|
||||
bytes key = 1;
|
||||
}
|
||||
```
|
||||
|
||||
#### 3. Chain key update
|
||||
@@ -286,7 +290,7 @@ The message key MUST be used to encrypt the next message to be sent.
|
||||
1. Inherits the security considerations of [X3DH](https://signal.org/docs/specifications/x3dh/#security-considerations)
|
||||
and [Double Ratchet](https://signal.org/docs/specifications/doubleratchet/#security-considerations).
|
||||
|
||||
2. Inherits the security considerations of the [Waku v2 protocol](../../core/10/waku2.md).
|
||||
2. Inherits the security considerations of the [Waku v2 protocol](/waku/standards/core/10/waku2.md).
|
||||
|
||||
3. The protocol is designed to be used in a decentralized manner, however,
|
||||
it is possible to use a centralized server to serve prekey bundles.
|
||||
@@ -299,7 +303,8 @@ It is possible to link messages signed by the same keypair.
|
||||
|
||||
## Copyright
|
||||
|
||||
Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
|
||||
Copyright and related rights waived via
|
||||
[CC0](https://creativecommons.org/publicdomain/zero/1.0/).
|
||||
|
||||
## References
|
||||
|
||||
@@ -308,7 +313,7 @@ Copyright and related rights waived via [CC0](https://creativecommons.org/public
|
||||
- [Signal's Double Ratchet](https://signal.org/docs/specifications/doubleratchet/)
|
||||
- [Protobuf](https://developers.google.com/protocol-buffers/)
|
||||
- [Off-the-Record protocol](https://otr.cypherpunks.ca/Protocol-v3-4.1.1.html)
|
||||
- [The Waku v2 protocol](../../core/10/waku2.md)
|
||||
- [The Waku v2 protocol](/waku/standards/core/10/waku2.md)
|
||||
- [HKDF](https://www.rfc-editor.org/rfc/rfc5869)
|
||||
- [2/ACCOUNT](https://specs.status.im/spec/2#x3dh-prekey-bundles)
|
||||
- [reference wire format](https://github.com/status-im/status-go/blob/a904d9325e76f18f54d59efc099b63293d3dcad3/services/shhext/chat/encryption.proto#L12)
|
||||
|
||||
Reference in New Issue
Block a user