Re: Ternary Encoding :-)

Rich wrote:

Stefan Claas <pollux@tilde.club> wrote:

Stefan Claas wrote:

Rich wrote:

Stefan Claas <pollux@tilde.club> wrote:

Rich wrote:

Stefan Claas <pollux@tilde.club> wrote:

Rich wrote:
 

Of course, this just brings to the front the OTP key distribution and
key reuse problems.

 
Forgot to mention, not with my programs, because also in this case I
can use for ternary xor encryption deterministic keys, valid for one
day (UTC +0000), so that border control does not find keys. :-)

 
You'll have to explain further, as the above is not nearly enough
explanation to understand what you are discussing.
 

I have made this a standard for some of my programs, because long ago
I thought of key distribution problems and looked for solutions,
which others afaik have not thought of (yet).

 
Further explanation needed.

 
Ok. You talked about key distribution problems with OTPs and management.
 
I have Go programs which can generate as many random keys/pads per day
(UTC +0000) for my programs, based on a shared secret, consisting of
a password and salt.
 
In order that this works Alice and Bob needs only one initial session,
where they transfer with a client/server program, which uses DHE/AES-GCM,
the shared secret via the Tor Network, to bypass third party servers
and NAT etc.
 
Once the shared secret is transfered securely to Alice or Bob, they use
the key generation programs, which are deterministic. This means that
when Alice generates todays pads/keys she does not need to transfer them
to Bob, because Bob has the shared secret and can generate the same
determenistic keys for each day (UTC +0000).
 
This procedure allows either Alice or Bob to travel, without worring that
some border patrol finds pads/keys, for daily usage, or If I would do
encryption with you without sending you pads in advance, via postal
service etc.

 
Then the weakness here is this "generator algorithm".  A OTP is only
perfectly secure if the pads are true random sequences.
 
Deterministic outputs from a seeded generator are not "true random
sequences" so you will not gain the "unbreakable" aspect of a proper
OTP.
 
Will it likely be /good enough/ such that those of us left here are
unlikely to break it: yes.  Will it be good enough that one of the
three-letter-agencies cannot break it: likely no.
 

 
That is old saying , that it is only unbreakable with TRRNG. I believe
that nowadays PRNG can serve the purpose as well, for OTP encryption.
 
What patterns would distinguish a TRNG and PRNG OTP sheet, if a
cryptanalist would look at them, or when looking at a couple of
more sheets? The difference is IMHO none.

 
Example, 60 dice rolls from random.org and Go's crypto/rand
 
random.org:
2 4 4 4 4 5 4 6 1 2 2 1 5 6 4
5 6 4 2 2 5 3 6 1 3 1 4 1 6 4
2 1 2 2 2 2 2 2 3 1 1 2 6 1 6
5 1 6 5 5 4 3 1 3 6 6 5 1 3 1
 
Go crypt/rand:
3 5 6 3 4 5 4 1 1 6 1 5 3 2 4
3 5 1 1 6 5 3 2 3 1 1 6 3 3 3
5 3 6 3 1 2 1 6 1 1 4 1 1 5 5
1 6 3 6 6 1 4 6 1 3 2 2 1 4 1

 
In just this one sample, go crypt/rand shows a bias (I'm surprised it
showed with such a small sample size).  Larger samples will likely show
other biases:
 
random.org
 
  count die face
     13 1
     13 2
      6 3
     10 4
      8 5
     10 6
 
go
 
  count die face
     18 1
      5 2
     13 3
      6 4
      8 5
     10 6
 
go rolled a "1" 18 times (random.org rolled no single face more than 13
times).  It also under-rolled a "2" vs.  the lowest count face
random.org returned.
 
And finding that simple bias only needed 'sort' and 'uniq' to do so. 
Running them through something like the die harder tests would likely
show other results.

Now I have used my PC's internal TRNG (TPM 2.0 Chip) via Go, instead of
crypt/rand and the process is slower but looks like this:

4 4 3 6 3 6 3 4 4 6 4 2 1 5 1
1 5 6 6 1 1 6 3 1 2 5 6 1 2 4
2 4 2 3 5 1 2 6 5 1 2 1 2 5 3
1 4 5 5 6 6 3 5 2 5 5 6 4 2 2

5 3 1 5 2 4 5 4 6 1 1 3 4 5 4
3 2 5 4 4 4 6 3 1 5 6 6 2 6 2
2 4 5 5 5 5 2 6 5 6 3 3 3 1 6
3 3 2 2 3 6 5 3 2 2 1 6 6 4 6

1 4 5 3 4 3 1 6 3 2 1 1 6 3 4
6 5 2 4 3 3 3 5 1 4 2 5 4 3 3
3 4 5 2 5 3 1 4 6 1 6 3 2 5 6
5 4 6 4 6 6 2 4 2 2 6 4 4 1 4

--
Regards
Stefan