Of course I know that you cannot directly use a random number R to generate a OpenPGP or RSA key. But there is a function such as x,y = f(R) where R is a random number (then usually taken from /dev/random) and x is a public key and y is a private key.
And the function f() does "generate" the key. If R is identical from 2 runs, then the same RSA keypair will came out. About timestamp, uid and expiration date. Uid could be a username input (Username/password login) while timestamp could be fixed, and no expiration date. About bitcoin, I know these clients and keys exist. My idea was just to implement it as a user-friendly package into tails so you can "boot from a seed" and get everything restored from seed. -----Ursprungligt meddelande----- Från: Tails-dev <tails-dev-boun...@boum.org> För s7r Skickat: den 15 juli 2018 14:41 Till: tails-dev@boum.org Ämne: Re: [Tails-dev] Suggestion: Determistic key generation option for completely read-only systems Hello, Sebastian Nielsen wrote: > I have a suggestion for tails, that will make it more useful for the > masses, and still having it completely read-only. > > > > And that is having, when the Tails OS starts up, there will be a > password prompt. > > > > This password prompt will accept any password. This passsword is then > used with PBKDF2 key strengtening to create a master key. Then this > master key is SHA512d concatenated with a counter, creating a CSPRNG > stream. (with a 32 bit counter there will be exactly 2 TB of randomness > before it start to repeat) > > (ergo: the first 512 bits is: Sha512( PBKDF2(password) + 0 ) , second > 512 bits = Sha512( PBKDF2(password) + 1 ), and so on). > > > > Then this CSPRNG stream is then used to create a PGP key, then a bitcoin > keypair (with adress and such), then a Tor keypair, and then a few other > keys, certificates and such needed for the system. Of course this should > not be fed into /dev/random, instead other ways is needed to correctly > inject this randomness in the key generation functions for OpenPGP and such. > > > > Of course, 2 different users starting up Tails and entering the > identical password will of course get the same PGP key, same bitcoin > keypair and such. > > This is not entirely true. You cannot generate PGP RSA keys this way, only ECC keys maybe (because the password might represent the point on the curve to regenerate the same key). Also the anatomy of a PGP key is not that simple. Basically in order to have the same PGP key it needs to have the same fingerprint, and the fingerprint doesn't just hash the key, it also includes the timestamp of creation, UID, expiration date, etc. And by design it should also have an ENCRYPTION subkey that has the same variables which might or might not be the same with the primary key ones. It's not simple for average users to enter these details at every boot, and it's very easy to mess it up and break stuff -- we should not recommend this practice. There is a reason why there's no "restore from seed / passphrase" option in GnuPG itself. For SSH keys used to authenticate to servers or sign commits, if they are RSA (which are the most common used) this will not work as well. It might work for EdDSA / Ed25519 but AFAIK deterministic generation of Ed25519 from passphrase / seed doesn't exist in any implementation currently, yet I don't see a reason why it couldn't be done. For Bitcoin this is unnecessary, as this is already supported. You can use Electrum wallet which is included in Tails and restore your wallet from seed every time you boot, ensuring everything remains the same by following a protocol standard widely tested and used. You are also not forced to use a 'seed' (string of 12 words or so) - you can have your own passphrase and when restoring the wallet instead of entering the string of words just paste the sha256(passphrase) and you'll have the same wallet. This is not bad and does not have any security flow, except users choosing a weak passphrase which is why the GUI doesn't explicitly tell you how to do this, but it allows you if you really want to and know what you are doing. We should always assume that regular users are inclined to use weak passwords and try to defend them from that by at least not making it explicit: "hey you can enter 1234 here as password easy to remember and you'll have a wallet". > > But the main advantage is that you dont need to store anything. Even if > your Tails installation media is seized, nothing can happen. You have > your password, thats all that is needed to recreate your installation > of Tails. > > Of course, the user needs to select a secure password. > > > > This also means any single tails installation media can be used by > unlimited users. And that would also make it more interesting for > internet cafés and such to install Tails on their public computers, > since tails then become completely read-only but still users can get > their PGP keys, bitcoin keys, and TOR keys and other keys by simply > logging in with the password they chose when first starting to use tails > at home. Earlier I addressed Bitcoin keys, PGP keys and SSH keys. I am not sure what you mean by Tor keys? Tails uses Tor in client mode (not relay mode) so there is no Tor keys to back up at all. You don't need anything. What would Tails need is a way to have the same Guard at every reboot for a limited guard lifetime, but this is a whole other topic and there are some ideas on the blueprint -- not an easy task. There are 0 reasons to run a relay on Tails (it would also be a huge PITA) so I won't discuss relay keys. Other than that, there is nothing in a Tor install that would be needed on every reboot. There are no keys, unless you are talking about onion service keys. If you are talking about onion service keys, Tails is not intended to be a server operating system (people that want to run onion services hosted should be using whonix / qubes-os or other server oriented stuff). Even if one would want to do onion service hosting on Tails and use it as a server operating system, the feature we are discussing here still won't work: a) v2 onion services use RSA 1024 keys. As I said above for PGP and SSH keys, RSA can't be regenerated from a passphrase. b) v3 onion services use Ed25519 keys. They were explicitly coded to support offline master key, so Tails should aim to let this feature be properly implemented upstream (in Tor). I am sure after this is implemented Tor will allow neat stuff like restoring your onion service from a string of words, or passphrase, because with ECC it's possible with relatively low risks given enough entropy. I am sorry about the "won't work" arguments, but as I see it this will complicate things for users, leave more attack surface and place for mistakes from average users this degrading their security level considerably, with no actual real benefit. I can see you have some knowledge in this field, so instead let me point you in a direction that would be really useful. Please help us with this: https://tails.boum.org/blueprint/persistent_Tor_state/ See what is the current plan, drawbacks and discarded ideas and help in taking the best decision here. -s7r
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.