3 ms·

For lack of an epistemological framework, we can call Kong a 4th generation wallet. If you'll bear with me: Paper Wallet were 1st gen - one couldn't guarantee

For lack of an epistemological framework, we can call Kong a 4th generation wallet. If you'll bear with me: Paper Wallet were 1st gen - one couldn't guarantee the person giving you a paper wallet didn't have two copies or kept a copy of the private key for themselves. Probably ok for personal use assuming you trust your printer firmware. Hardware Wallets were 2nd gen - seed phrases made recovering from device loss nice but again, seed phrases were designed to be exported and cant be used as cash. They are very useful for other applications. Java smart cards were 3rd gen - meant to be used as pre-paid gift cards but again these were designed for banks who wanted to handle the key material in software and have dangerous APIs for doing such[1]. Kong - uses a specific kind of secure element which allows for key generation but not extraction. On chain contracts convert the R1 keys used by the chip to K1 used by most cryptocurrencies today. The paper goes in depth on this in section 2.3 [2] [1] https://docs.oracle.com/javacard/3.0.5/api/javacard/security/DSAPrivateKey.html https://docs.oracle.com/javacard/3.0.5/api/javacard/security... [2] https://ipfs.io/ipfs/QmRNRCocj4PwKMXrd1jeUGw7ASQSuEk7BDJu5KsGuWBXAX https://ipfs.io/ipfs/QmRNRCocj4PwKMXrd1jeUGw7ASQSuEk7BDJu5Ks...

userbinator 7y ago
Kong - uses a specific kind of secure element which allows for key generation but not extraction In other words, just like almost every other smartcard (including EMV).
- paulgerhardt 7y ago
  See section 2.2 in the whitepaper [1]. There is not an industry specific term that succinctly captures these requirements. Secure element isn't ideal but it's not an HSM or TPM. PUF's are a feature not a chip category. If it's programmable, we don't want to touch it. That goes for most smart cards / java cards. EMV cards specifically have 'get private key' API's which would not work for this application. [1] https://ipfs.io/ipfs/QmRNRCocj4PwKMXrd1jeUGw7ASQSuEk7BDJu5KsGuWBXAX https://ipfs.io/ipfs/QmRNRCocj4PwKMXrd1jeUGw7ASQSuEk7BDJu5Ks...

userbinator 7y ago

Kong - uses a specific kind of secure element which allows for key generation but not extraction In other words, just like almost every other smartcard (including EMV).

paulgerhardt 7y ago
See section 2.2 in the whitepaper [1]. There is not an industry specific term that succinctly captures these requirements. Secure element isn't ideal but it's not an HSM or TPM. PUF's are a feature not a chip category. If it's programmable, we don't want to touch it. That goes for most smart cards / java cards. EMV cards specifically have 'get private key' API's which would not work for this application. [1] https://ipfs.io/ipfs/QmRNRCocj4PwKMXrd1jeUGw7ASQSuEk7BDJu5KsGuWBXAX https://ipfs.io/ipfs/QmRNRCocj4PwKMXrd1jeUGw7ASQSuEk7BDJu5Ks...