Jump to content
TiffanyHayden

Working on a new hardware wallet for XRP

Recommended Posts

Guest
42 minutes ago, tulo said:

It corresponds to @JoelKatz :rolleyes:...is that the secret project? :D

My bet is Nik.   He replied to this thread.  

@teddybear   I have reread the xilobyte thread.  He explicitly says assuming it is accessible.  They claim it is not.  So I'm sticking to my foolish belief that the hardware is safe online. :)   (Happy to be shown as wrong though...)

@TiffanyHayden feature idea...   i was thinking Bluetooth output to a app acting as a screen for the device.   But I think that's too risky.

Instead if the device can send output via https to the server website and the user can browse to it (the server site)....  using a auth key displayed on device to login...

Then you could make all RCL features and settings available to the wallet for the user to use...   including trading.

 

Edited by Guest

Share this post


Link to post
Share on other sites
1 hour ago, Sukrim said:

I'd like to see an Open Source secret storage implementation for JavaCard, so it is possible to load a hardware wallet software on any JavaCard compatible smart card instead of having to rely on custom hardware in relatively limited capacity and often being the first design of its kind.

I'm not sure one needs fully-fledged "hardware wallet software" on JavaCard smartcards. There are already existing open-source JavaCard applets that can generate & store private keys and sign message digests with ECDSA. JavaCard supports secp256k1 curve AFAIK, too, and there's no need to implement this curve manually.

Everything else can be implemented in software on your computer.

 

 

Share this post


Link to post
Share on other sites
11 hours ago, T8493 said:

I'm not sure one needs fully-fledged "hardware wallet software" on JavaCard smartcards. There are already existing open-source JavaCard applets that can generate & store private keys and sign message digests with ECDSA. JavaCard supports secp256k1 curve AFAIK, too, and there's no need to implement this curve manually.

Everything else can be implemented in software on your computer.

You mean https://github.com/LedgerHQ/ledger-javacard or similar? I don't remember the standard being extended to allow secp256k1 signatures with SHA256, but that might have changed.

I agree that most of the stuff can (and imho should) be implemented in wallet software on the client, not the hardware token. At most maybe a way to display what you're signing out of band (could even just be a LED blinking morse code + a decoder app/website for phones), though I'd still rather have a tried and true hardware platform than some custom design by amateurs/enthusiasts.

One issue is that a lot of people still want to export the private key. An ideal use case for generating a main key offline and signing a transaction that enables the (secret) key of the hardware wallet as well as a second transaction that takes back control. Then you can keep the key of the smart card hidden even from yourself and still recover from a lost piece of hardware.

Share this post


Link to post
Share on other sites
1 hour ago, Sukrim said:

You mean https://github.com/LedgerHQ/ledger-javacard or similar? I don't remember the standard being extended to allow secp256k1 signatures with SHA256, but that might have changed.

I was thinking about something even simpler, e.g. 

https://github.com/Yubico/ykneo-curves/blob/master/applet/src/com/yubico/ykneo/curves/YkneoCurves.java

(there are other implementations, too, I also suspect some of them are even compatible with PKCS#11)

Basically this is just a wrapper around javacard.security package which supports secp256k1 natively (code just sets appropriate EC domain parameters: https://github.com/Yubico/ykneo-curves/blob/master/applet/src/com/yubico/ykneo/curves/SecP256k1.java )

 

This code supports only two operations: generate and sign. Maybe one could add import/export of private keys.

But from the cryptographic point of view this should be probably enough.

 

Share this post


Link to post
Share on other sites
15 minutes ago, T8493 said:

However, before anybody codes anything serious that deals with private keys instead of secret keys, I think this RippleAPI issue has to be sorted out: https://github.com/ripple/ripple-lib/issues/797

Whoever uses ripple-lib for a wallet these days is in for a world of hurt anyways. A solution for your issue seems to be https://github.com/ripple/ripple-lib/pull/769 which is in limbo since June.

Share this post


Link to post
Share on other sites

Make it so that's it's a bracelet, a ring, a keychain, whatever. 
Custom color/skins chosen by the buyer and voila.

Oh well I'd buy it *shrugs*

Share this post


Link to post
Share on other sites
28 minutes ago, Sukrim said:

Whoever uses ripple-lib for a wallet these days is in for a world of hurt anyways.

Sure, but what are the other options? Unmaintaned & incomplete java and C# libraries?

 

Share this post


Link to post
Share on other sites
25 minutes ago, T8493 said:

Sure, but what are the other options? Unmaintaned & incomplete java and C# libraries?

Using only "submit" calls to rippled and writing the transaction creation stuff yourself. There's not that much going on in ripple-lib anyways and the JS style used is hard to read and reason about for me at least. Most of the heavy lifting you still have to do yourself or rely on (unreliable) external services like the Data API. The few things you'd actually use in ripple-lib are just a few lines or functions in any modern programming language.

Share this post


Link to post
Share on other sites
1 minute ago, Sukrim said:

Using only "submit" calls to rippled and writing the transaction creation stuff yourself. There's not that much going on in ripple-lib anyways and the JS style used is hard to read and reason about for me at least. Most of the heavy lifting you still have to do yourself or rely on (unreliable) external services like the Data API. The few things you'd actually use in ripple-lib are just a few lines or functions in any modern programming language.

You are referring to "simple" queries. But there are some quite hard-to-do-it-right things, like transaction submission workflow or transaction parsing or serialization.

 

Share this post


Link to post
Share on other sites
10 minutes ago, T8493 said:

You are referring to "simple" queries. But there are some quite hard-to-do-it-right things, like transaction submission workflow or transaction parsing or serialization.

ripple-lib doesn't really help with submission and parsing/serialization is not really that hard. The golang implementation by rubblelabs for example is quite straightforward, or you just read through rippled or ripple-lib.

Share this post


Link to post
Share on other sites

That's a great initiative.  I would think that there is an opportunity to out price the competitors you mentioned.  A pricing strategy in the range ~$49 vs $99. On the other hand, they all kind have that same, plain feel right now.  No reason it couldn't be both practical and slick too.  

Edited by cryptoman

Share this post


Link to post
Share on other sites
Guest

Yes it is... code rots...

 You need a large user base to justify code maintence... oh, oh...

:-)

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×
×
  • Create New...