BitShares Forum
Other => Graveyard => Keyhotee => Topic started by: HackFisher on December 06, 2013, 05:34:37 am
-
As I understood, there is a private key related to Keyhotee ID, do I need to retrieve the private key each time I do an operation with Keyhotee?
Encryption of private key means need to provide the password each time of a operation/session, that reduce the easy of use, but if not, The risk could be very high if we must access private key very often, do Keyhotee have any good solution to this?
Besides, need to access private often means it is impossible to store the private key offline(cold storage), which is different with the case of Bitcoin, bitcoin need private key only when you decide to start a transaction, this is not very often.
And Bitcoin can easily tranfer coins in one wallet to another, but Keyhotee seems not easy to transfer the reputation and honer of one ID to another.
What should I do if my private key has potential risk to leak?
Here is a link from Chinese Forum asking the same question, refer:
keyhotee 发布在即，我有一个疑问。
就是keyhotee ID的私钥是否能够冷存储，而不影响每次的登录认证。
因为我始终担心私钥存储在联网的电脑上所面临的安全威胁。
私钥一旦泄漏，除了删除ID没有别的选择。而在连线电脑上，被木马入侵很难彻底杜绝。
不知道即将发布的keyhotee系统是否考虑了这个问题并给出了对策。
-
Keyhotee asks you for your password when you start the program and will keep your private key in memory only. On disk it is always encrypted.
In order to process incoming messages your private key needs to be 'live' at all times. There is no way around that.
With the wallet system you only need your private key for sending money.
Bottom line, you are relying on the physical security of your computer and OS while Keyhotee is open. Any bright ideas on how to improve that?
-
Is the password some fixed password using md5 stored on disk like Linux OS, or some Encrypt Interface could be customized by users?
I think it may be possible to add 2-factor auth if there is such encrypt interface, ex. using SMS or Google Authenticator. I still have no idea whether it is meaningless to do this.
For the bottom line and OS level, I know there are a lot of software with root/administrator authority to the OS, can hook to api call, and capture datas, including some anti-virus softwares. I don't whether we could to do something to avoid this?
Keyhotee asks you for your password when you start the program and will keep your private key in memory only. On disk it is always encrypted.
In order to process incoming messages your private key needs to be 'live' at all times. There is no way around that.
With the wallet system you only need your private key for sending money.
Bottom line, you are relying on the physical security of your computer and OS while Keyhotee is open. Any bright ideas on how to improve that?
-
Is the password some fixed password using md5 stored on disk like Linux OS, or some Encrypt Interface could be customized by users?
I think it may be possible to add 2-factor auth if there is such encrypt interface, ex. using SMS or Google Authenticator. I still have no idea whether it is meaningless to do this.
For the bottom line and OS level, I know there are a lot of software with root/administrator authority to the OS, can hook to api call, and capture datas, including some anti-virus softwares. I don't whether we could to do something to avoid this?
Keyhotee asks you for your password when you start the program and will keep your private key in memory only. On disk it is always encrypted.
In order to process incoming messages your private key needs to be 'live' at all times. There is no way around that.
With the wallet system you only need your private key for sending money.
Bottom line, you are relying on the physical security of your computer and OS while Keyhotee is open. Any bright ideas on how to improve that?
Authentication and Encryption are two different things. Authentication such as google authenticator can answer a 'yes' | 'no' question but does not protect a private key. So we could add Google Authenticator at launch but an attacker who got a copy of the wallet on your disk would still be searching for the password/key that is protecting it.
-
Is the password some fixed password using md5 stored on disk like Linux OS, or some Encrypt Interface could be customized by users?
I think it may be possible to add 2-factor auth if there is such encrypt interface, ex. using SMS or Google Authenticator. I still have no idea whether it is meaningless to do this.
For the bottom line and OS level, I know there are a lot of software with root/administrator authority to the OS, can hook to api call, and capture datas, including some anti-virus softwares. I don't whether we could to do something to avoid this?
Keyhotee asks you for your password when you start the program and will keep your private key in memory only. On disk it is always encrypted.
In order to process incoming messages your private key needs to be 'live' at all times. There is no way around that.
With the wallet system you only need your private key for sending money.
Bottom line, you are relying on the physical security of your computer and OS while Keyhotee is open. Any bright ideas on how to improve that?
Authentication and Encryption are two different things. Authentication such as google authenticator can answer a 'yes' | 'no' question but does not protect a private key. So we could add Google Authenticator at launch but an attacker who got a copy of the wallet on your disk would still be searching for the password/key that is protecting it.
OK, I got it, thanks.
-
wow
-
wow
Explain the nature of your 'wow'?
-
wow
Explain the nature of your 'wow'?
It seems some company names like google/apple/ebay were registered here just now. Are they robots?
Sorry to out of thread :D
-
Keyhotee asks you for your password when you start the program and will keep your private key in memory only. On disk it is always encrypted.
In order to process incoming messages your private key needs to be 'live' at all times. There is no way around that.
With the wallet system you only need your private key for sending money.
Bottom line, you are relying on the physical security of your computer and OS while Keyhotee is open. Any bright ideas on how to improve that?
I really want to store the private key offline.
How about this way.
We use 2 private key,mainkey and subkey,with different power(or we can say:usage).
They work like this.
1,I generate a mainkey on an offline PC,then I use it to register my kehotee ID.
mainkey<->kehotee ID
2,I generate a subkey and sign this information(subkey's publickey + "active subkey") with my mainkey on offline pc.
then I broadcast this info to p2pnet.I use subkey to login,decrypt, signature and etc.
mainkey->active subkey
subkey->login
subkey->send mail
subkey->read mail
subkey->delete my mail from p2pnet
3,If my subkey was lost or leaked,I can sign information(subkey's publickey + "destroy subkey") with my mainkey
and broadcast it to p2pnet.Attacker maybe already see my history mail,but he cannot do anything more
when I destroyed my old subkey and active a new subkey.
Most important thing is,I don't have to destroy my kehotee ID,Specifically my founder ID.And Attacker cannot
destroy my kehotee ID with only subkey too.
mainkey->destroy subkey
mainkey->destroy ID
4,My keyhotee ID is totally safe now.
We can make more function with mainkey and subkey.
:-)
-
Keyhotee asks you for your password when you start the program and will keep your private key in memory only. On disk it is always encrypted.
In order to process incoming messages your private key needs to be 'live' at all times. There is no way around that.
With the wallet system you only need your private key for sending money.
Bottom line, you are relying on the physical security of your computer and OS while Keyhotee is open. Any bright ideas on how to improve that?
I really want to store the private key offline.
How about this way.
We use 2 private key,mainkey and subkey,with different power(or we can say:usage).
They work like this.
1,I generate a mainkey on an offline PC,then I use it to register my kehotee ID.
mainkey<->kehotee ID
2,I generate a subkey and sign this information(subkey's publickey + "active subkey") with my mainkey on offline pc.
then I broadcast this info to p2pnet.I use subkey to login,decrypt, signature and etc.
mainkey->active subkey
subkey->login
subkey->send mail
subkey->read mail
subkey->delete my mail from p2pnet
3,If my subkey was lost or leaked,I can sign information(subkey's publickey + "destroy subkey") with my mainkey
and broadcast it to p2pnet.Attacker maybe already see my history mail,but he cannot do anything more
when I destroyed my old subkey and active a new subkey.
Most important thing is,I don't have to destroy my kehotee ID,Specifically my founder ID.And Attacker cannot
destroy my kehotee ID with only subkey too.
mainkey->destroy subkey
mainkey->destroy ID
4,My keyhotee ID is totally safe now.
We can make more function with mainkey and subkey.
:-)
good idea
-
Keyhotee asks you for your password when you start the program and will keep your private key in memory only. On disk it is always encrypted.
In order to process incoming messages your private key needs to be 'live' at all times. There is no way around that.
With the wallet system you only need your private key for sending money.
Bottom line, you are relying on the physical security of your computer and OS while Keyhotee is open. Any bright ideas on how to improve that?
I really want to store the private key offline.
How about this way.
We use 2 private key,mainkey and subkey,with different power(or we can say:usage).
They work like this.
1,I generate a mainkey on an offline PC,then I use it to register my kehotee ID.
mainkey<->kehotee ID
2,I generate a subkey and sign this information(subkey's publickey + "active subkey") with my mainkey on offline pc.
then I broadcast this info to p2pnet.I use subkey to login,decrypt, signature and etc.
mainkey->active subkey
subkey->login
subkey->send mail
subkey->read mail
subkey->delete my mail from p2pnet
3,If my subkey was lost or leaked,I can sign information(subkey's publickey + "destroy subkey") with my mainkey
and broadcast it to p2pnet.Attacker maybe already see my history mail,but he cannot do anything more
when I destroyed my old subkey and active a new subkey.
Most important thing is,I don't have to destroy my kehotee ID,Specifically my founder ID.And Attacker cannot
destroy my kehotee ID with only subkey too.
mainkey->destroy subkey
mainkey->destroy ID
4,My keyhotee ID is totally safe now.
We can make more function with mainkey and subkey.
:-)
good idea
I like this idea... implementing it will double the bandwidth and storage costs of the network, but it would dramatically increase security and provide much better protection for your identity. In fact, so much better that I might be tempted to slip the release date to include it. Thanks, send me a PTS address for a tip.
-
Keyhotee asks you for your password when you start the program and will keep your private key in memory only. On disk it is always encrypted.
In order to process incoming messages your private key needs to be 'live' at all times. There is no way around that.
With the wallet system you only need your private key for sending money.
Bottom line, you are relying on the physical security of your computer and OS while Keyhotee is open. Any bright ideas on how to improve that?
I really want to store the private key offline.
How about this way.
We use 2 private key,mainkey and subkey,with different power(or we can say:usage).
They work like this.
1,I generate a mainkey on an offline PC,then I use it to register my kehotee ID.
mainkey<->kehotee ID
2,I generate a subkey and sign this information(subkey's publickey + "active subkey") with my mainkey on offline pc.
then I broadcast this info to p2pnet.I use subkey to login,decrypt, signature and etc.
mainkey->active subkey
subkey->login
subkey->send mail
subkey->read mail
subkey->delete my mail from p2pnet
3,If my subkey was lost or leaked,I can sign information(subkey's publickey + "destroy subkey") with my mainkey
and broadcast it to p2pnet.Attacker maybe already see my history mail,but he cannot do anything more
when I destroyed my old subkey and active a new subkey.
Most important thing is,I don't have to destroy my kehotee ID,Specifically my founder ID.And Attacker cannot
destroy my kehotee ID with only subkey too.
mainkey->destroy subkey
mainkey->destroy ID
4,My keyhotee ID is totally safe now.
We can make more function with mainkey and subkey.
:-)
nice!
-
Keyhotee asks you for your password when you start the program and will keep your private key in memory only. On disk it is always encrypted.
In order to process incoming messages your private key needs to be 'live' at all times. There is no way around that.
With the wallet system you only need your private key for sending money.
Bottom line, you are relying on the physical security of your computer and OS while Keyhotee is open. Any bright ideas on how to improve that?
I really want to store the private key offline.
How about this way.
We use 2 private key,mainkey and subkey,with different power(or we can say:usage).
They work like this.
1,I generate a mainkey on an offline PC,then I use it to register my kehotee ID.
mainkey<->kehotee ID
2,I generate a subkey and sign this information(subkey's publickey + "active subkey") with my mainkey on offline pc.
then I broadcast this info to p2pnet.I use subkey to login,decrypt, signature and etc.
mainkey->active subkey
subkey->login
subkey->send mail
subkey->read mail
subkey->delete my mail from p2pnet
3,If my subkey was lost or leaked,I can sign information(subkey's publickey + "destroy subkey") with my mainkey
and broadcast it to p2pnet.Attacker maybe already see my history mail,but he cannot do anything more
when I destroyed my old subkey and active a new subkey.
Most important thing is,I don't have to destroy my kehotee ID,Specifically my founder ID.And Attacker cannot
destroy my kehotee ID with only subkey too.
mainkey->destroy subkey
mainkey->destroy ID
4,My keyhotee ID is totally safe now.
We can make more function with mainkey and subkey.
:-)
Good idea!
I think this idea may also apply to prove of stake, we may use a subkey for the purpose of verifying the owner of stake, this subkey is for this purpose only, cannot do transactions, so we can keep mainkey offline and safe.
Sent from my GT-N7100 using Tapatalk
-
Good idea!
I think this idea may also apply to prove of stake, we may use a subkey for the purpose of verifying the owner of stake, this subkey is for this purpose only, cannot do transactions, so we can keep mainkey offline and safe.
Sent from my GT-N7100 using Tapatalk
I don't quite sure if this is technically possible. Sounds nice idea, too!
-
Good idea!
I think this idea may also apply to prove of stake, we may use a subkey for the purpose of verifying the owner of stake, this subkey is for this purpose only, cannot do transactions, so we can keep mainkey offline and safe.
Sent from my GT-N7100 using Tapatalk
I don't quite sure if this is technically possible. Sounds nice idea, too!
Further more, I think we could extend this idea of mainkey-subkey to a more common model/service, used to integrate different DAC services, it can separate the risk of lost private key, increase the dynamic flexibility of Keyhotee because key relationship are stored/broadcast through blockchain.
For Keyhotee, I don't know finally how will it be implemented technically. But I think it would be very interesting if not just simple using a subkey for some purpose(e.g. send emails). How about using tag for a subkey, the tag represent some DAC service(e.g. Integrate bitcoin wallet to send BTCs), we may not want to share one key for both email and btc wallet.
We can even import the wallet key of Bitcoin as a subkey of Keyhotee, just binding to some tag and the main key, in that way, we can implement great features like direct send someone BTC just need to know his Keyhotee ID(if he has a bitcoin tag binded), and SSO, keep his btc wallet dat private. This is implemented by query his Bitcoin address by query the subkey bind to "Bitcoin" Tag of Keyhotee ID, balabala...... I can imagine more cases like this, I saw a snapshot of Keyhotee wallet, there seems already have similar feature, I have no idea whether they are implemented this way, maybe its time to views the source codes.
Willing to know more details about this, I have more interest in Keyhotee now, for its potential to guard the privacy and ability to integrate DACs as ID management.
-
I happen to read some posts with similar ideas to resolve similar questions from PPC community, they might be helpful to the topic, honor belongs to @clar
Just quote and add the link here, still not fully understand them though.
https://bitcointalk.org/index.php?topic=115608.msg1319290#msg1319290 (https://bitcointalk.org/index.php?topic=115608.msg1319290#msg1319290)
Quote from: Jutarul on November 06, 2012, 03:20:01 AM
Maybe we should organize a bounty for this?
I think you need to consider this 'feature' more carefully before raising a bounty. It may be a serious 'bug' if implemented poorly.
Giving away a copy of the stake signing key has no risk for the user whatsoever, but the signing keys are valuable to an attacker. Therefore, an attacker could purchase up all the signing keys really
cheap and attack the network. The attack could not be stopped. (attacker could refuse to allow anyone to include txns that revoke the sign key). This must be avoided. Offline stake creation also seems like a bad idea for similar reasons.
Stake signing should not be a risk-free process. Risk-free private keys should not exist.
A better solution is to make two keys: one high-functionality high-risk key, one low-functionality low-risk key.
a) The high risk key can do anything. The high risk key can also move all the coins at once, invalidating the low risk key.
b) The low risk private key can spend 0.01% of its balance per block. Enforce this as follows. Every txn signed by the low risk key must send at least 10000 satoshis to its own public key address for every 1 satoshi sent to another address or used as a txn fee. [this is a block validity rule; txns that don't obey this cannot be included in blocks] This key can then be depleted at a maximum rate of about 1.5% per day.The low risk key can also provide proof-of-stake. You can expose this key to the network at low risk. You might share it with a well-trusted party. You wouldn't share this key with an anonymous individual however.
Each wallet should list two types of balances: Spending and saving
1) Savings wallets are unencytped. Savings wallets have low risk private keys online and unencrypted and high risk private keys in cold storage. Savings wallets try to provide PoS.
2) Spending wallets are optionally encrypted. They should have both the low risk private key and the high risk private key online. These wallets cannot provide PoS if they are encrypted.
Users can shift coins back and forth as needed. This is a good improvement for three reasons.
1) It makes stake provision safer
2) It makes the currency safer to use in general (i.e. now it would be like you can call the credit company and report your private key stolen. Think how many unlucky bitcoin users have wanted to do this at some point.)
3) Convenience is maintained because the spending wallet still provides the traditional functionality.
-----------------------
https://bitcointalk.org/index.php?topic=194054.0 (https://bitcointalk.org/index.php?topic=194054.0)
Abstract: A proposal to relieve stake minter the risk of running online hot wallet.
Description: This proposal is simpler than the previous dual-key proposal [1]. A special transaction type called cold-locked transaction is introduced so that a designated spending address is specified in its first output. Protocol enforces that, spending of any of the outputs in the transaction must be sent to this designated address, or to itself (for stake generation purpose). When stake is generated, the stake transaction is also cold-locked and the designated key in stake must match all designated keys where all the inputs come from.
How hot wallet is protected:
By providing a cold-wallet address as the designated spending address in cold-locked transactions, stake minter can now run their entire balance online in a hot wallet to earn 1% annual interest with minimum risk, while providing maximum security to the entire network. This would allow even the exchanges, pools, and other online wallet providers to participate in network protection without risking public assets, and reduce fees or even pay interest to its users.
For public review and discussion.
References:
[1] https://bitcointalk.org/index.php?topic=115608.0
-
What if each key had a parent key, a list of subkeys, a list of supported application GUIDs and a human readable subtitle string? All reputation alterations and checks would propagate up to the root. Either a key's own signature or that of a parent would be necessary for revocation, and both signatures would be required to form new subkey relationships. Subkeys could be used on lower security devices when necessary to avoid risking the primary, particularly if it were a founder's ID. The GUID list would inform others of what currencies could be received by the particular key, as well as what other applications the key supported. The subtitle string could be used to label a key as home, work, or mobile, or to label a key for contributions to a particular project.
Subkeys wouldn't need names registered in the blockchain, since they don't have their own reputation.
-
Keyhotee asks you for your password when you start the program and will keep your private key in memory only. On disk it is always encrypted.
In order to process incoming messages your private key needs to be 'live' at all times. There is no way around that.
With the wallet system you only need your private key for sending money.
Bottom line, you are relying on the physical security of your computer and OS while Keyhotee is open. Any bright ideas on how to improve that?
Might be a good idea to make use of the trusted platform module.