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 SHA512’d 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 don’t 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
