Re: Ternary Encoding :-)

Rich wrote:

Stefan Claas <pollux@tilde.club> 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.

 
You can believe what you wish.  But for your belief to be accepted by
more than yourself you'll need to show a proof of such.  Neither of us
being a "cryptographer" I'll continue to believe the existing proofs
that for an OTP to be secure the pad needs to be generated from a true
random source.
 

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.

 
Any deterministic generator system (i.e., a PRNG) is going to have some
bias somewhere (possibly not noticable until a significant number of
outputs are analyzed).  It will be that bias that will provide the
crack through which an actual cryptographer will break the system.
 

Like with my previous reply I use now my PC's internal TRNG (TPM 2.0 Chip)
with Go and can now generate true random ternary numbers for OTP sheets. :-)

These are now not deterministic and the key distribution problem comes up,
but at least this was a learning exercise and I may update other Go programs
of mine.

--
Regards
Stefan