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.

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

ECDH Encryption with Carbonado #1

Open
cryptoquick opened this issue Feb 13, 2024 · 3 comments
Open

ECDH Encryption with Carbonado #1

cryptoquick opened this issue Feb 13, 2024 · 3 comments

Comments

@cryptoquick
Copy link

Carbonado can be used to encrypt consignment bytes. It's recommended that consignments are decoded before put into Carbonado format, and to specify c7 format (compression, encryption, stream verification, without error correction codes, because RGB proxy does not require durability), then transmitted and stored as binary.

Carbonado keys are derived using NIP-06, which makes wallet support easier.

This doesn't actually require much of the proxy server since this would just be an end to end encryption standard between wallets, just that it can receive and store files in binary and not just text, and perhaps it might need to associate or communicate the ECDH PK.

What does everyone think? If folks think it's a good idea, I can write up a spec PR.

@fedsten
Copy link

fedsten commented Feb 14, 2024

I think that an encrypted proxy server is very needed and desirable, but I would work on it as a separate project rather than changing the current one. A simpler unencrypted proxy is still useful for testing and for people that wish to self host their server, so since RGB supports multiple transfer protocol I believe the best way is to first define a new encrypted transfer protocol, and then create a new project that implements it.

@22388o
Copy link

22388o commented Feb 14, 2024

Interesting idea. It is not necessary run Carbonado node to e2e? The proxy will receive information automatically?

@22388o
Copy link

22388o commented Feb 14, 2024

I think that an encrypted proxy server is very needed and desirable, but I would work on it as a separate project rather than changing the current one. A simpler unencrypted proxy is still useful for testing and for people that wish to self host their server, so since RGB supports multiple transfer protocol I believe the best way is to first define a new encrypted transfer protocol, and then create a new project that implements it.

Make sense. I guess we can create separate project and see how works.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants