add yellow paper #1

ymatto · 2025-09-06T01:15:45Z

No description provided.

codecov · 2025-09-06T01:17:39Z

Welcome to Codecov 🎉

Once you merge this PR into your default branch, you're all set! Codecov will compare coverage reports and display results in all future pull requests.

Thanks for integrating Codecov - We've got you covered ☂️

Sajjon · 2025-09-06T13:36:18Z

yellow_paper/images/dsq_system_diagram.png

Hmm, Keypair N column is a bit wrong. Should rather be Entropy N. Such that the tuple (Question, Salt, Answer) is the input and Entropy is the output.

Then the N rows in the Entropy Column should be "expanded" (become more) into n choose m many in a Combinations column and then the Combinations should be "collapsed" (reduced) into byte array from which we form the symmetric encryption keys.

Then we have the secret to protect as input and paired which each encryption key, forming the output cipher (not output private key, there is no asymmetric keys/PKI involved here at all).

Perhaps that is too much for graphics, then we can at least do something like Input tuples of (Question, Salt, Answer) in a column -> box instead of columns for our procedure and output be encryption keys, and then pair each encryption key with secret to protect and output being output ciphers.

I don't think we should try to get full detail into this diagram because is just meant to provide a simple guide to the concept of combining the questions/answers/salt into separate encryptions. But I take your point about saying "Entropy" and that "secret" is probably the better thing to show here. (I think in practice that secret will often be used to create a keypair that can be used to derive and control a crypto account, but I can just explain that and use the more correct "secret" in this diagram and in the paper.)

Sajjon · 2025-09-06T13:37:31Z

yellow_paper/yellow_paper.md

+To take the example in the diagram above, we might offer the question *“What was the year, make, and model of your first car?”* The three elements of the question allow us to break up the answer into three distinct parts. For “year” and “make”, we can even offer answers as selection lists of all possible years and auto manufacturers so that there can be no ambiguity, leaving only the “model” as freeform text. Then, the processing on that answer can reduce the example answer to “golftdi” so that later variations in the answer like “Golf TDI”, “golf tdi”, or “GOLF TDi” are all correct.
+
+
+### Multiple encrypted output private key packages


Hmm, "output private key packages" is a bit inaccurate - see my comment above on the graphics.

So ### Multiple encryptions ?

Agreed, going with "Multiple encryptions of the secret"

Sajjon · 2025-09-06T13:40:09Z

yellow_paper/yellow_paper.md

+
+### Multiple encrypted output private key packages
+
+Once we have a keypair for each of the questions/answers, we can use them to protect a single final output private key. We encrypt the output private key into multiple packages using different combinations of question/answer key pairs to provide the level of failsafe-ness we desire.


Suggested change

Once we have a keypair for each of the questions/answers, we can use them to protect a single final output private key. We encrypt the output private key into multiple packages using different combinations of question/answer key pairs to provide the level of failsafe-ness we desire.

Once we have encryption keys for each of the questions/answers (more than one encryption key per `(Question, Answer, Salt)` tuple since we do `n choose m`), we can use them to protect our `secret` (typically a BIP39 Mnemonic). By encrypting the secret using different combinations of question/answer/salt we provide the level of failsafe-ness we desire.

Agreed in principle, rewording a bit.

Sajjon · 2025-09-06T13:41:11Z

yellow_paper/yellow_paper.md

+
+Once we have a keypair for each of the questions/answers, we can use them to protect a single final output private key. We encrypt the output private key into multiple packages using different combinations of question/answer key pairs to provide the level of failsafe-ness we desire.
+
+For example, if we want to ask 3 questions but allow the user to answer any 2, we encrypt the output private key with every combination of 2 question/answer key pairs – 3 combinations in this case. This means that success in answering at least any 2 of the questions will allow one of the packages to be decrypted and the output private key temporarily recovered just for the duration of its use.


Suggested change

For example, if we want to ask 3 questions but allow the user to answer any 2, we encrypt the output private key with every combination of 2 question/answer key pairs – 3 combinations in this case. This means that success in answering at least any 2 of the questions will allow one of the packages to be decrypted and the output private key temporarily recovered just for the duration of its use.

For example, if we want to ask 3 questions but allow the user to answer any 2, we encrypt the secret with every combination of 2 question/answer key pairs – 3 combinations in this case. This means that success in answering at least any 2 of the questions will allow one of the encryptions to be decrypted and the secret temporarily recovered just for the duration of its use.

Sajjon · 2025-09-06T13:45:03Z

yellow_paper/yellow_paper.md

+
+For example, if we want to ask 3 questions but allow the user to answer any 2, we encrypt the output private key with every combination of 2 question/answer key pairs – 3 combinations in this case. This means that success in answering at least any 2 of the questions will allow one of the packages to be decrypted and the output private key temporarily recovered just for the duration of its use.
+
+In a real system design, the choice of the number of questions, and the number of encrypted key packages, should strike a suitable balance between increased security (more questions, fewer packages allowing for fewer incorrect answers) and increased reliability (fewer questions, more packages allowing for more incorrect answers). This choice may be influenced by things like the guessability of the questions/answers for the users in question, and how the output private key is used in the account’s multi-signature structure.


Suggested change

In a real system design, the choice of the number of questions, and the number of encrypted key packages, should strike a suitable balance between increased security (more questions, fewer packages allowing for fewer incorrect answers) and increased reliability (fewer questions, more packages allowing for more incorrect answers). This choice may be influenced by things like the guessability of the questions/answers for the users in question, and how the output private key is used in the account’s multi-signature structure.

In a real system design, the choice of the number of questions, and the number of minimum correct answers, should strike a suitable balance between increased security (more questions, lower minumum correct answers allowed) and increased reliability (fewer questions, more incorrect answers allowed). This choice may be influenced by things like the guessability of the questions/answers for the users in question, and how the secret is used in the account’s multi-signature structure (e.g. letting the secret be a BIP39 mnemonic from which private keys are derived).

Agreed in principle, rewording a bit.

Sajjon · 2025-09-06T13:48:34Z

yellow_paper/yellow_paper.md

+* The salt used to create the question/answer keypairs
+* The list of questions corresponding to the keypairs created
+
+With these things, a wallet may perform the authentication by offering the questions (and the structure of their answers), using the answers and salt to decrypt at least one of the packages, and recovering the output private key for use.


Suggested change

With these things, a wallet may perform the authentication by offering the questions (and the structure of their answers), using the answers and salt to decrypt at least one of the packages, and recovering the output private key for use.

With these things, a wallet may perform the authentication by offering the questions (and the structure of their answers), using the answers and salt to decrypt at least one of the encryptions, and recovering the secret for use.

Sajjon · 2025-09-06T14:04:11Z

yellow_paper/yellow_paper.md

+
+This does put some burden on the wallet software. Crypto wallets typically assume the idea that the user has written down their private key (or corresponding mnemonic seed phrase) and so that is the only information required to recover access. With the decentralized security questions concept, the wallet software has a responsibility to save the additional information that enables easy use of authentication using the security questions. That includes likely a backup mechanism of some kind to ensure access to this data even if, for example, a phone is lost.
+
+The idea of backing up this data (perhaps even in the cloud) sounds concerning on the surface. However, note that the package of data is not "security critical" on its own. If an attacker is able to access this data, they have no ability to make use of the output private key without finding the correct answers to the security questions. With sufficient entropy in the choice of questions and structured answers, the best they have achieved is narrowing down the list of questions to answer for a social engineering attack, if they are able to research the answers for the user in question or phish the answers from them.


Suggested change

The idea of backing up this data (perhaps even in the cloud) sounds concerning on the surface. However, note that the package of data is not "security critical" on its own. If an attacker is able to access this data, they have no ability to make use of the output private key without finding the correct answers to the security questions. With sufficient entropy in the choice of questions and structured answers, the best they have achieved is narrowing down the list of questions to answer for a social engineering attack, if they are able to research the answers for the user in question or phish the answers from them.

The idea of backing up this data (perhaps even in the cloud) sounds concerning on the surface. However, note that the package of data is not "security critical" on its own. If an attacker is able to access this data, they have no ability to make use of the encryptions without finding the correct answers to the security questions. With sufficient entropy in the implementors choice of questions and structured answers, the best they have achieved is narrowing down the list of questions to answer for a social engineering attack, if they are able to research the answers for the user in question or phish the answers from them.

Sajjon · 2025-09-06T14:17:01Z

yellow_paper/yellow_paper.md

+
+The idea of backing up this data (perhaps even in the cloud) sounds concerning on the surface. However, note that the package of data is not "security critical" on its own. If an attacker is able to access this data, they have no ability to make use of the output private key without finding the correct answers to the security questions. With sufficient entropy in the choice of questions and structured answers, the best they have achieved is narrowing down the list of questions to answer for a social engineering attack, if they are able to research the answers for the user in question or phish the answers from them.
+
+While this means that cryptographic security is maintained in the case of a revealed data package, it does mean that the output private key the system protects should be considered "less secure" than the traditional “pure” private key that the user has securely written down somewhere that no one can discover it. This is the primary reason that we do **not** recommend this system be used to protect a private key that wields *exclusive* or *primary* control over an account, but rather as a secondary "factor" in a multi-signature scheme.


Suggested change

While this means that cryptographic security is maintained in the case of a revealed data package, it does mean that the output private key the system protects should be considered "less secure" than the traditional “pure” private key that the user has securely written down somewhere that no one can discover it. This is the primary reason that we do **not** recommend this system be used to protect a private key that wields *exclusive* or *primary* control over an account, but rather as a secondary "factor" in a multi-signature scheme.

While this means that secret is not revealed in the case of a leaked data package, it does mean that the secret the system protects should be considered "more compromised" than if the secret was never input into the system. This is the primary reason that we do **not** recommend this system be used to protect a private key that wields *exclusive* or *primary* control over an account, but rather as a secondary "factor" in a multi-signature scheme.

Sajjon · 2025-09-06T14:18:44Z

yellow_paper/yellow_paper.md

+
+Similarly, we can use decentralized security questions not for the *primary* private key used for everyday cryptocurrency account access, but as a *secondary* factor used as part of recovery of access. This may, for example, enable the *primary* key to be one that is secure but *losable*, such as a key stored securely on a mobile phone. If the primary key is lost (perhaps by losing a phone), decentralized security questions may be used as part of a multi-signature method to update the account to use a different primary key.
+
+We can describe such a system using some features of the Radix Network.


Suggested change

We can describe such a system using some features of the Radix Network.

We can describe such a system using some features of the [Radix Network](https://www.radixdlt.com/).

Sajjon · 2025-09-06T14:19:24Z

yellow_paper/yellow_paper.md

+
+We can describe such a system using some features of the Radix Network.
+
+The Radix Network includes "smart accounts" – essentially smart contracts that act as accounts that hold user tokens and can include multi-signature logic to define how those accounts may be used in various ways. One of the ways Radix uses this capability is the possibility of having different "roles" for smart accounts that have different rights and are controlled by different sets of private keys.


Suggested change

The Radix Network includes "smart accounts" – essentially smart contracts that act as accounts that hold user tokens and can include multi-signature logic to define how those accounts may be used in various ways. One of the ways Radix uses this capability is the possibility of having different "roles" for smart accounts that have different rights and are controlled by different sets of private keys.

The Radix Network includes ["smart accounts"](https://learn.radixdlt.com/article/what-are-smart-accounts) – essentially smart contracts that act as accounts that hold user tokens and can include multi-signature logic to define how those accounts may be used in various ways. One of the ways Radix uses this capability is the possibility of having different "roles" for smart accounts that have different rights and are controlled by different sets of private keys.

add yellow paper

8d75021

Sajjon requested changes Sep 6, 2025

View reviewed changes

ymatto added 3 commits September 8, 2025 15:29

Yellow paper updates

9dae0fc

Yellowpaper update

ae0529e

yellowpaper update

fe03cd3

Sajjon merged commit 7f34abc into main Sep 10, 2025
8 checks passed

		To take the example in the diagram above, we might offer the question “What was the year, make, and model of your first car?” The three elements of the question allow us to break up the answer into three distinct parts. For “year” and “make”, we can even offer answers as selection lists of all possible years and auto manufacturers so that there can be no ambiguity, leaving only the “model” as freeform text. Then, the processing on that answer can reduce the example answer to “golftdi” so that later variations in the answer like “Golf TDI”, “golf tdi”, or “GOLF TDi” are all correct.


		### Multiple encrypted output private key packages


		### Multiple encrypted output private key packages

		Once we have a keypair for each of the questions/answers, we can use them to protect a single final output private key. We encrypt the output private key into multiple packages using different combinations of question/answer key pairs to provide the level of failsafe-ness we desire.

	Once we have a keypair for each of the questions/answers, we can use them to protect a single final output private key. We encrypt the output private key into multiple packages using different combinations of question/answer key pairs to provide the level of failsafe-ness we desire.
	Once we have encryption keys for each of the questions/answers (more than one encryption key per `(Question, Answer, Salt)` tuple since we do `n choose m`), we can use them to protect our `secret` (typically a BIP39 Mnemonic). By encrypting the secret using different combinations of question/answer/salt we provide the level of failsafe-ness we desire.


		Once we have a keypair for each of the questions/answers, we can use them to protect a single final output private key. We encrypt the output private key into multiple packages using different combinations of question/answer key pairs to provide the level of failsafe-ness we desire.

		For example, if we want to ask 3 questions but allow the user to answer any 2, we encrypt the output private key with every combination of 2 question/answer key pairs – 3 combinations in this case. This means that success in answering at least any 2 of the questions will allow one of the packages to be decrypted and the output private key temporarily recovered just for the duration of its use.


		For example, if we want to ask 3 questions but allow the user to answer any 2, we encrypt the output private key with every combination of 2 question/answer key pairs – 3 combinations in this case. This means that success in answering at least any 2 of the questions will allow one of the packages to be decrypted and the output private key temporarily recovered just for the duration of its use.

		In a real system design, the choice of the number of questions, and the number of encrypted key packages, should strike a suitable balance between increased security (more questions, fewer packages allowing for fewer incorrect answers) and increased reliability (fewer questions, more packages allowing for more incorrect answers). This choice may be influenced by things like the guessability of the questions/answers for the users in question, and how the output private key is used in the account’s multi-signature structure.

	With these things, a wallet may perform the authentication by offering the questions (and the structure of their answers), using the answers and salt to decrypt at least one of the packages, and recovering the output private key for use.
	With these things, a wallet may perform the authentication by offering the questions (and the structure of their answers), using the answers and salt to decrypt at least one of the encryptions, and recovering the secret for use.


		This does put some burden on the wallet software. Crypto wallets typically assume the idea that the user has written down their private key (or corresponding mnemonic seed phrase) and so that is the only information required to recover access. With the decentralized security questions concept, the wallet software has a responsibility to save the additional information that enables easy use of authentication using the security questions. That includes likely a backup mechanism of some kind to ensure access to this data even if, for example, a phone is lost.

		The idea of backing up this data (perhaps even in the cloud) sounds concerning on the surface. However, note that the package of data is not "security critical" on its own. If an attacker is able to access this data, they have no ability to make use of the output private key without finding the correct answers to the security questions. With sufficient entropy in the choice of questions and structured answers, the best they have achieved is narrowing down the list of questions to answer for a social engineering attack, if they are able to research the answers for the user in question or phish the answers from them.


		The idea of backing up this data (perhaps even in the cloud) sounds concerning on the surface. However, note that the package of data is not "security critical" on its own. If an attacker is able to access this data, they have no ability to make use of the output private key without finding the correct answers to the security questions. With sufficient entropy in the choice of questions and structured answers, the best they have achieved is narrowing down the list of questions to answer for a social engineering attack, if they are able to research the answers for the user in question or phish the answers from them.

		While this means that cryptographic security is maintained in the case of a revealed data package, it does mean that the output private key the system protects should be considered "less secure" than the traditional “pure” private key that the user has securely written down somewhere that no one can discover it. This is the primary reason that we do not recommend this system be used to protect a private key that wields exclusive or primary control over an account, but rather as a secondary "factor" in a multi-signature scheme.


		Similarly, we can use decentralized security questions not for the primary private key used for everyday cryptocurrency account access, but as a secondary factor used as part of recovery of access. This may, for example, enable the primary key to be one that is secure but losable, such as a key stored securely on a mobile phone. If the primary key is lost (perhaps by losing a phone), decentralized security questions may be used as part of a multi-signature method to update the account to use a different primary key.

		We can describe such a system using some features of the Radix Network.


		We can describe such a system using some features of the Radix Network.

		The Radix Network includes "smart accounts" – essentially smart contracts that act as accounts that hold user tokens and can include multi-signature logic to define how those accounts may be used in various ways. One of the ways Radix uses this capability is the possibility of having different "roles" for smart accounts that have different rights and are controlled by different sets of private keys.

add yellow paper #1

add yellow paper #1

Uh oh!

Conversation

ymatto commented Sep 6, 2025

Uh oh!

codecov bot commented Sep 6, 2025

Welcome to Codecov 🎉

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants