first of all: Im pretty paranoid. I am creating a seed on my linux server using the following command:

cat /dev/urandom |tr -dc A-Z9|head -c${1:-81} 

Since I don´t have any local linux systems, I connect to my external server via SSH.

Now, I got this (probally unjustified) fear, that my seed, although being transferred via SSH, might be compromised. So I considered shuffling the seed on my local computer. For example taking parts of it (5-10 digits) and pasting them at a differnt location.

I guess that this might decrease the security/entropy of the seed. My questions is: how much? Should I either trust that my seed has been transmitted safely or shuffle it around a bit?

Of course I know the easiest solution would be using a local Linux system to generate it. But let´s talk about the other solutions.

  • $\begingroup$ Not everyone uses *nix, so a short explanation of what this command actually does would help solicit more informed answers... $\endgroup$ – Paul Uszak Sep 6 '17 at 18:56

I can understand paranoia. They're probably recording everything I type.

There's good paranoia of the sort that gets the adrenaline pumping, sharpens the reflexes and gives you the energy to turn that sabre tooth tiger into dinner and moccasins. Unfortunately, I think that you might be suffering from the bad type of paranoia. This has led you to think irrationally (sorry).

Let's assume that your urandom seed is generated magically and is cryptographicly safe, and uniformly distributed. It's about as good as its going to get without a true random number generator. You then transmit it and the bad people read it. Is this your compromised? So security = 0.

You then start manipulating it by slice and dice. This is a speculative calculation, but I would suggest that the only security you add is the decision where to chop the seed. So if you chopped and swapped a 32 byte (256 bit) seed at some random place, you add log2(32) bits of entropy. That's 5 bits. Perhaps you add another 5 if you chop and swap again. Ultimately though, you can only generate an absolute maximum of 32! byte permutations /combinations. It will be less in reality as some bytes might be equal (and I can't do the maths). That's a maximum of 118 bits, which is less than half of your original entropy. And you have to realise that a human is very poor at thinking of random things in his head. The 5 bits might actually only be 4 or even less. (Have scientific studies been done of human generated entropy?)

You can see where bad paranoia can take you? Taking of other solutions, urandom isn't magic. It's a CSPRNG (SHA1 or ChaCha) which you either have on your client computer, or can implement using one of the many kosher algorithms. You might even have access to a Windows version of /dev/urandom if that's your bent.

In summary, it all falls apart when you believe THEY read your SSH traffic.


If you ssh into your Linux server, your local ssh client will randomly pick a secret number $c$, and transmit over the internet the element $g^c$ of some group $G$ (written multiplicatively) and for some standard base point $g \in G$.

($G$ is almost always either $(\mathbb Z/p\mathbb Z)^\times$, the group of multiplicative integers modulo $p$, for a ~2048-bit safe prime $p$; or $E(\mathbb F_p)$, the group of $\mathbb F_p$-rational points on an elliptic curve $E$, for a ~256-bit prime $p$. But these details are not important.)

An adversary eavesdropping on the network who can guess $c$ can decrypt the entire ssh session, and thereby obtain the seed $s$ your server transmitted back to you. It doesn't matter how hard it is for the adversary to guess $s$ if they can guess $c$.

Next, on the client, you randomly pick a permutation $\pi$ of seeds, and use $s' = \pi(s)$. For example, perhaps the seed $s$ is 128-bit string, and $\pi = \operatorname{AES256}_k$, where $k$ is a 256-bit key chosen at random. If the adversary can guess $c$, it's hard to imagine they can't guess $\pi$ too. If you could choose a 256-bit key uniformly at random without the adversary guessing it, then:

  1. Why didn't you just use $s' = k$ in the first place, instead of sshing into your Linux server?
  2. If you insist on sshing into your Linux server, why couldn't you use that for $c$ in the first place?

(You suggested a much less sophisticated choice of seed permutation. You could also pick a function that's not a permutation, such as $\operatorname{HMAC-SHA256}_k$, which will lose a negligible amount of entropy. It doesn't really matter which family of permutations or functions you choose to tweak the seed—by Kerkchoffs' principle, you should assume the adversary knows what family of functions you're using.)


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.