Ecosyste.ms: Awesome

An open API service indexing awesome lists of open source software.

Awesome Lists | Featured Topics | Projects

https://github.com/cedarmist/dapp-rosemigrate

Migrate Rose from Consensus to Sapphire, dApp using Wagmi & Oasis
https://github.com/cedarmist/dapp-rosemigrate

oasis rose sapphire typescript wagmi

Last synced: 20 days ago
JSON representation

Migrate Rose from Consensus to Sapphire, dApp using Wagmi & Oasis

Awesome Lists containing this project

README 

        
# Sign-Into-Oasis-With-Ethereum (SIOWE)



Uses Sign-In-With-Ethereum ([SIWE]) to derive an Oasis Staking keypair.



This allows for ROSE to be received from `oasis1...` addresses at the consensus

level then transferred to Sapphire without installing the Oasis extension or the

Oasis Web Wallet.



![image](https://github.com/CedarMist/dapp-rosemigrate/assets/134699267/b56267a7-1c46-4da2-916d-4919682d8014)



[SIWE]: https://eips.ethereum.org/EIPS/eip-4361



## SIWE Key Derivation



```python

secret = SHA512(SIWE(eip4361Message))

```



This requires [ECDSA] ([RFC-6979]) signing to be deterministic to derive the same key

every time, additionally the Nonce & IssuedAt dates are hard-coded, essentially

everybody is signing the same message to derive 128 bytes of entropy in a way

which can only be generated by the keyholder.



```python

def SIWE(msg):

    h = SHA256(msg)

    k = HMAC256(privateKey, h)

    R = k*G

    r = R.x

    return dict(r=r, s=k^-1 * (h + (r*privateKey)))

```



The signature can then be used as seed for a key-pair, or used as the root of a

BIP32 HD wallet. Because logging in with the same Ethereum account via

Sign-In-With-Ethereum works consistently across different devices, wallets and

libraries you will login to the same account every time you access the dApp

with that wallet.



[RFC-6979]: https://datatracker.ietf.org/doc/html/rfc6979#section-3.2

[ECDSA]: https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm



## ChatGPT Notes on mapping



Sure, let's break down the process of mapping `HMAC(privateKey, SHA256(msg))` into a 512-bit domain via ECDSA, and examine its cryptographic and algebraic properties.



### Step-by-Step Process



   1. Message Hashing:

        * Compute the [SHA-256] hash of the message `msg`:

            * `hash=SHA-256(msg)`

        * The result is a 256-bit hash value.



   2. HMAC with Private Key:

        * Compute the HMAC of the hash using a private key:

            * `hmac_output=HMAC(privateKey,hash)`

        * [HMAC] is a keyed hash function that produces a 256-bit output when using SHA-256.



   3. ECDSA Signature Generation:

        * Use the HMAC output as the message to sign with ECDSA:

            * `signature=ECDSA_sign(privateKey,hmac_output)`

        * The ECDSA signature typically consists of two components, `r` and `s`, each of which is a 256-bit integer.



   4. Mapping to 512-bit Domain:

        * Concatenate `r` and `s` to form a 512-bit value:

            * `mapped_output=r∥s`



[HMAC]: https://www.rfc-editor.org/rfc/rfc2104

[SHA-256]: https://en.wikipedia.org/wiki/SHA-2



### Cryptographic Properties



   1. HMAC Properties:

        * **Keyed Hash:** HMAC uses a private key and a hash function, ensuring that the output is only computable by someone who knows the private key.

        * **Collision Resistance:** HMAC inherits the collision resistance of the underlying hash function (SHA-256), making it infeasible to find two different inputs that produce the same HMAC output.

        * **Message Authentication:** HMAC provides integrity and authenticity, ensuring that the message hash has not been tampered with.



   2. ECDSA Properties:

        * **Digital Signature:** ECDSA provides a way to sign data such that the signature can be verified using the corresponding public key.

        * **Security Assumptions:** ECDSA security is based on the difficulty of the elliptic curve discrete logarithm problem ([ECDLP]).

        * **Deterministic Signature:** If deterministic signing (RFC 6979) is used, ECDSA will produce the same signature for the same message and key, removing the need for a random nonce.



   3. Mapping Properties:

        * **512-bit Output:** By concatenating the `r` and `s` values of the ECDSA signature, we map the HMAC output into a 512-bit domain.

        * **Unique Mapping:** Given the same private key and message, the process will always produce the same 512-bit output due to the deterministic nature of HMAC and ECDSA.



[ECDLP]: https://rtullydo.github.io/cryptography-notes/section-ecdlp.html



### Algebraic Properties



   1. Elliptic Curve Operations:

        * The ECDSA signature generation involves elliptic curve point multiplications and modular arithmetic.

        * `r` is derived from the x-coordinate of a point on the elliptic curve, while `s` is computed using modular inverses and the private key.



   2. Deterministic Mapping:

        * The process is deterministic due to the use of HMAC and deterministic ECDSA (if applicable). This means the same inputs will always yield the same output.



   3. Concatenation:

        * The concatenation of `r` and `s` to form a 512-bit value is a simple algebraic operation that preserves the uniqueness of the ECDSA signature components.



### Security Considerations



   1. Key Management:

        * The private key used in HMAC and ECDSA must be securely managed and protected. Compromise of the private key would compromise the entire process.



   2. Hash Function Strength:

        * The security of the scheme depends on the cryptographic strength of SHA-256. Any weaknesses in SHA-256 would affect the overall security.



   3. HMAC Integrity:

        * HMAC provides strong integrity guarantees. However, the choice of the private key and proper implementation are crucial for maintaining these guarantees.



   4. ECDSA Implementation:

        * Proper implementation of ECDSA is essential to avoid vulnerabilities like weak random number generation (if non-deterministic ECDSA is used) and side-channel attacks.



By carefully considering these cryptographic and algebraic properties and ensuring secure implementation practices, the process of mapping `HMAC(privateKey, SHA256(msg))` into a 512-bit domain via ECDSA can provide robust security guarantees.