krypton-android
krypton-android copied to clipboard
backup or key extraction option
with its current state with no backup option how can i trust this for any sensitive operations. we are considering computer thread landscape that other apps can interact etc, how about mobile threats, device getting stolen, lost, bricked all legitimate conditions. with no backup in place if a key was used just as a single entity somewhere i would be looking at a loss of access to that box.
any thoughts on how to avoid that besides suggesting configuring another key coz since you only have one key in place (#38) per key i need a new app/phone
We currently store the private key in the Android Keystore (secure hardware) and there is no way to export the key. We are planning to add support to optionally not keep it in the Android Keystore to work up to a backup story (i.e. copying the private key to another backup phone running Kryptonite or paper backup).
While it's better security practice to never export the private key, especially for hosted services like GitHub, redeployable infrastructure, and servers to which multiple people have access, we understand your use case and we're actively working on it.
Just something to note @agrinman, this isn't just the OP's use-case. It's everyones' use-case. I wouldn't use this unless I could get a copy of the key (even in encrypted form) backed up somewhere like on paper, or to the cloud, or even to my laptop.
Something similar to Authy's backup policy would be nice. The keys are encrypted client-side and then backed up in the cloud. When restoring, the user logs in and supplies the decryption key.
I think everyone understands the use-case, and @agrinman clearly wrote that they're working on it. However, it comes with a very significant reduction in key safety over the current approach. For that reason, it's not everyone's use-case.
@joushou that is exactly the point, the app is holding the key too tight for even comfort of its own users. losing phone as phones crashing is not as rare as it may sound, can happen any single day. compared to a laptop or desktop losing phones is far more easier. what then, i am fine if the good folks decide that we don't want this feature, we don't think this scenario is useful for us etc but then at that same time don't claim it as an end solution for everything. when someone comes out and puts a blog post end of id_rsa that's a big claim. and just the two issues this and #38 are clearly the reason people using ssh keys for day to day operations would not be in a position to use this software.
If you are a one off githubber keys don't matter, for those who do care about keys they will not have single key for everything nor will have no backup at all solution. so if not everyone, it will still be required for the massive or power users. Again like i said fine if you don't want to cater to those users, they can rot in ssh-agent hell (pun intended) but you need to be clear that if you do want to support them its a no-go as of now.
So while i appreciate @agrinman suggesting they are working on it, i would not go on a limb and claim this is as of today a replacement solution for current processes. and i would not try to relegate this as a corner case also.
We are working on this feature, stay tuned :)
It would be nice to also have a feature to have revocation certificate extraction. This is the proper way to handle lost keys
We really want to backup everything. For me, I would like to back up things into a password protected rar file. Then i will put it in my old USB HardDrive.
When i need, i will recovery things from the backup file
Now some time has passed, what is the progress like? Our ops engineers were quite enthusiastic about the idea, but to be able to use it company-wide, we lack exactly this feature.