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
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
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.
Från: Tails-dev <email@example.com> För s7r
Skickat: den 15 juli 2018 14:41
Ämne: Re: [Tails-dev] Suggestion: Determistic key generation option for
completely read-only systems
Post by Sebastian Nielsen
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
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
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".
Post by Sebastian Nielsen
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 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
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
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
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:
See what is the current plan, drawbacks and discarded ideas and help in
taking the best decision here.