fiatjaf/nos2x

Feature: read nsec from an encrypted qrcode

Opened this issue · 6 comments

antonioconselheiro commented

I have developed a solution that enables modern men to securely store their sensitive keys within encrypted physical structures, employing information encryption through a printed QR code.

I am the integration of a browser plugin with and prompt the user for the decryption key.
I am proposing to add to the browser plugin the capability to read the nsec from an encrypted QR code and ask the user for the opening key.
I believe we should instruct the user to only read qrcodes that were generated by hin.

The benefits of this mechanism are the possibility of removing my nsec from digital media, since a qrcode can be written not only with the ink of a printer, but also on wood, fiber or metal.

I am available to implement this solution if you approve the request.

Private QRCode App:
private qrcode preview

fiatjaf commented

This is cool, but we need it to be standardized so it works with all other Nostr clients. There are already some clients doing nsec encryption, and would be nice to get everybody to use the same algorithm before we implement anything.

  • 👍2
antonioconselheiro commented

nice, in private qrcode I'm using an encode that allows me to parameterize which algorithm is being used:

encrypted:[algorithm]?[args];[cypher]

encrypted: identify the string as encrypted encode
algorithm: algorithm name
args: algorithm arguments
cypher: cypher, encrypted content

Example

encrypted:aes?iv=249704f119c3d09e4e0fb3b6a275e519;U2FsdGVkX1/mxOv5WpmRGHXZouip6GOw+P+Jdks6c1Z/uMfwBl7Me+dzJjioF72z9E+bKY/GlcL8HlWnWrs7fTlqVvzmsC3b2dm+JfL2rTH+60dNlk6PJ+41pLRDWA/l

See if this idea can contribute to this standardization

fiatjaf commented

I don't like that at all. Having parameters in the encryption thing just forces everybody to implement all possible parameters.

  • 👍1
antonioconselheiro commented

Nostr can support a single one algorithm with standardized parameters, this encode helps, if the future demands it, to add new algorithms and parameters keeping backwards compatibility.

My suggestion of encrypted encode is inspired by the data url specification (the parameters idea I got from NIP4):

data:[<mediatype>][;base64],<data>
data:text/plain,Hello%20World

As I said before, I am available to implement this feature to your plugin if you wish, following your decisions.

antonioconselheiro commented

So, NIP49 implementation is the standardized way to solves this?

fiatjaf commented

I guess yes.

I had forgotten about this issue.

  • 👍1