echo 'Happy News Year 2025' | ternary
2112102022020111101010222211010022112012102120110020100021120220
10000111010121200020221000211000220022020

$ echo 'Happy News Year 2025' | ternary | ternary -d
Happy News Year 2025

(My program works with binary data as well.)

--
Regards
Stefan

Stefan Claas wrote:
>
> echo 'Happy News Year 2025' | ternary
> 2112102022020111101010222211010022112012102120110020100021120220
> 10000111010121200020221000211000220022020
>
> $ echo 'Happy News Year 2025' | ternary | ternary -d
> Happy News Year 2025
>
> (My program works with binary data as well.)
>

The nice thing is we can like xor use ternary exclusive or (txor)
to encrypt/decrypt messages. :-)

$ echo 'Happy News Year 2025' | ternary > message.txt
$ txor -k k-1.txt < message.txt > message_encrypted.txt
$ txor -k k-1.txt -d < message_encrypted.txt > message_decrypted.txt
$ ternary -d < message_decrypted.txt
Happy News Year 2025

--
Regards
Stefan

Stefan Claas <pollux@tilde.club> wrote:
> Stefan Claas wrote:
>>
>> echo 'Happy News Year 2025' | ternary
>> 2112102022020111101010222211010022112012102120110020100021120220
>> 10000111010121200020221000211000220022020
>>
>> $ echo 'Happy News Year 2025' | ternary | ternary -d
>> Happy News Year 2025
>>
>> (My program works with binary data as well.)
>>
>
> The nice thing is we can like xor use ternary exclusive or (txor)
> to encrypt/decrypt messages. :-)
>
> $ echo 'Happy News Year 2025' | ternary > message.txt
> $ txor -k k-1.txt < message.txt > message_encrypted.txt
> $ txor -k k-1.txt -d < message_encrypted.txt > message_decrypted.txt
> $ ternary -d < message_decrypted.txt
> Happy News Year 2025

How does "ternary exclusive or" differ from the usual boolean xor?

Provided one can "xor" binary data, there's zero need for any odd
'encoding specific' xor operation. Just do a binary xor and be done.

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

Rich wrote:
> Stefan Claas <pollux@tilde.club> wrote:
> > Stefan Claas wrote:
> > >
> > > echo 'Happy News Year 2025' | ternary
> > > 2112102022020111101010222211010022112012102120110020100021120220
> > > 10000111010121200020221000211000220022020
> > >
> > > $ echo 'Happy News Year 2025' | ternary | ternary -d
> > > Happy News Year 2025
> > >
> > > (My program works with binary data as well.)
> > >
> >
> > The nice thing is we can like xor use ternary exclusive or (txor)
> > to encrypt/decrypt messages. :-)
> >
> > $ echo 'Happy News Year 2025' | ternary > message.txt
> > $ txor -k k-1.txt < message.txt > message_encrypted.txt
> > $ txor -k k-1.txt -d < message_encrypted.txt > message_decrypted.txt
> > $ ternary -d < message_decrypted.txt
> > Happy News Year 2025
>
> How does "ternary exclusive or" differ from the usual boolean xor?

The usual Boolean XOR (exclusive or) operation takes two binary inputs
and returns true (1) if exactly one of the inputs is true (1), and false
(0) otherwise.

Ternary XOR takes three binary inputs and returns true (1) if an odd
number of the inputs are true (1).

The ternary XOR differs from the usual XOR in that it considers three
inputs instead of two and returns true when an odd number of these
inputs are true.

> Provided one can "xor" binary data, there's zero need for any odd
> 'encoding specific' xor operation. Just do a binary xor and be done.

I wanted to visualize with the numbers 0,1,2 the Ternary numbers,
in an encoding scheme for ASCII transmission of the payload and that
the output can be compared with:

https://calculator.name/baseconvert/hexadecimal/ternary/
> Of course, this just brings to the front the OTP key distribution and
> key reuse problems.

Use it locally with your best friends. :-)

--
Regards
Stefan

Stefan Claas wrote:
> Rich wrote:
> > Stefan Claas <pollux@tilde.club> wrote:
> > > Stefan Claas wrote:
> > > >
> > > > echo 'Happy News Year 2025' | ternary
> > > > 2112102022020111101010222211010022112012102120110020100021120220
> > > > 10000111010121200020221000211000220022020
> > > >
> > > > $ echo 'Happy News Year 2025' | ternary | ternary -d
> > > > Happy News Year 2025
> > > >
> > > > (My program works with binary data as well.)
> > > >
> > >
> > > The nice thing is we can like xor use ternary exclusive or (txor)
> > > to encrypt/decrypt messages. :-)
> > >
> > > $ echo 'Happy News Year 2025' | ternary > message.txt
> > > $ txor -k k-1.txt < message.txt > message_encrypted.txt
> > > $ txor -k k-1.txt -d < message_encrypted.txt > message_decrypted.txt
> > > $ ternary -d < message_decrypted.txt
> > > Happy News Year 2025
> >
> > How does "ternary exclusive or" differ from the usual boolean xor?
>
> The usual Boolean XOR (exclusive or) operation takes two binary inputs
> and returns true (1) if exactly one of the inputs is true (1), and false
> (0) otherwise.
>
> Ternary XOR takes three binary inputs and returns true (1) if an odd
> number of the inputs are true (1).

XOR:

A B A⊕B
0 0 0
0 1 1
1 0 1
1 1 0

Ternary XOR:

A B C A⊕B⊕C
0 0 0 0
0 0 1 1
0 1 0 1
0 1 1 0
1 0 0 1
1 0 1 0
1 1 0 0
1 1 1 1

--
Regards
Stefan

Stefan Claas wrote:
> Stefan Claas wrote:
> > Rich wrote:
> > > Stefan Claas <pollux@tilde.club> wrote:
> > > > Stefan Claas wrote:
> > > > >
> > > > > echo 'Happy News Year 2025' | ternary
> > > > > 2112102022020111101010222211010022112012102120110020100021120220
> > > > > 10000111010121200020221000211000220022020
> > > > >
> > > > > $ echo 'Happy News Year 2025' | ternary | ternary -d
> > > > > Happy News Year 2025
> > > > >
> > > > > (My program works with binary data as well.)
> > > > >
> > > >
> > > > The nice thing is we can like xor use ternary exclusive or (txor)
> > > > to encrypt/decrypt messages. :-)
> > > >
> > > > $ echo 'Happy News Year 2025' | ternary > message.txt
> > > > $ txor -k k-1.txt < message.txt > message_encrypted.txt
> > > > $ txor -k k-1.txt -d < message_encrypted.txt > message_decrypted.txt
> > > > $ ternary -d < message_decrypted.txt
> > > > Happy News Year 2025
> > >
> > > How does "ternary exclusive or" differ from the usual boolean xor?
> >
> > The usual Boolean XOR (exclusive or) operation takes two binary inputs
> > and returns true (1) if exactly one of the inputs is true (1), and false
> > (0) otherwise.
> >
> > Ternary XOR takes three binary inputs and returns true (1) if an odd
> > number of the inputs are true (1).
>
> XOR:
>
> A B A⊕B
> 0 0 0
> 0 1 1
> 1 0 1
> 1 1 0
>
> Ternary XOR:
>
> A B C A⊕B⊕C
> 0 0 0 0
> 0 0 1 1
> 0 1 0 1
> 0 1 1 0
> 1 0 0 1
> 1 0 1 0
> 1 1 0 0
> 1 1 1 1

$ echo -n 'Hello sci.crypt!' > message.txt

$ ternary < message.txt
1221201211220001100200101212212002212101111121202210002002121022
1111101022101001

$ xxd -ps < message.txt
48656c6c6f207363692e637279707421

<https://www.webconversiononline.com/number-conversion.aspx?number=48656c6c6f207363692e637279707421&from=hexadecimal&to=ternary>

--
Regards
Stefan

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. :-)

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).

--
Regards
Stefan

Stefan Claas <pollux@tilde.club> wrote:
> Rich wrote:
>> Of course, this just brings to the front the OTP key distribution
>> and key reuse problems.
>
> Use it locally with your best friends. :-)

You still have a "distribution" problem, in that each "key file" must
be used only once. So you still have to get fresh pads to your
friends.

You've reduced the scale from "getting OTPs behind enemy lines" to
"getting OTPs to friends". But it still exists.

Stefan Claas <pollux@tilde.club> wrote:
> Stefan Claas wrote:
>> Rich wrote:
>> > Stefan Claas <pollux@tilde.club> wrote:
>> > > Stefan Claas wrote:
>> > > >
>> > > > echo 'Happy News Year 2025' | ternary
>> > > > 2112102022020111101010222211010022112012102120110020100021120220
>> > > > 10000111010121200020221000211000220022020
>> > > >
>> > > > $ echo 'Happy News Year 2025' | ternary | ternary -d
>> > > > Happy News Year 2025
>> > > >
>> > > > (My program works with binary data as well.)
>> > > >
>> > >
>> > > The nice thing is we can like xor use ternary exclusive or (txor)
>> > > to encrypt/decrypt messages. :-)
>> > >
>> > > $ echo 'Happy News Year 2025' | ternary > message.txt
>> > > $ txor -k k-1.txt < message.txt > message_encrypted.txt
>> > > $ txor -k k-1.txt -d < message_encrypted.txt > message_decrypted.txt
>> > > $ ternary -d < message_decrypted.txt
>> > > Happy News Year 2025
>> >
>> > How does "ternary exclusive or" differ from the usual boolean xor?
>>
>> The usual Boolean XOR (exclusive or) operation takes two binary inputs
>> and returns true (1) if exactly one of the inputs is true (1), and false
>> (0) otherwise.
>>
>> Ternary XOR takes three binary inputs and returns true (1) if an odd
>> number of the inputs are true (1).
>
> XOR:
>
> A B A⊕B
> 0 0 0
> 0 1 1
> 1 0 1
> 1 1 0
>
> Ternary XOR:
>
> A B C A⊕B⊕C
> 0 0 0 0
> 0 0 1 1
> 0 1 0 1
> 0 1 1 0
> 1 0 0 1
> 1 0 1 0
> 1 1 0 0
> 1 1 1 1

Or simply "even parity".

https://en.wikipedia.org/wiki/Parity_bit

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.

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.

--
Regards
Stefan

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.

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.

--
Regards
Stefan

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

--
Regards
Stefan

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.

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.

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

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

Stefan Claas wrote:

> 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.

For the key distribion over the Internet I work on a solution with Tor Hidden
Services and Diffie-Hellman key exchange, using AES-GCM.

My old pads program is already updated. It compiled flawlessly for many
different platforms, including macOS, but I do not know if they all support
TPM 2.0, like Windows and Linux does.

https://github.com/706f6c6c7578/pads

--
Regards
Stefan

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

The sort uniq 'distribution' now looks like this for the above:

count die face
25 1
29 2
30 3
32 4
31 5
33 6

Would have to run the 'rolls' throuogh die harder to learn any more.

Stefan Claas <pollux@tilde.club> wrote:
> Stefan Claas wrote:
>
>> 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.
>
> For the key distribion over the Internet I work on a solution with Tor Hidden
> Services and Diffie-Hellman key exchange, using AES-GCM.
>
> My old pads program is already updated. It compiled flawlessly for many
> different platforms, including macOS, but I do not know if they all support
> TPM 2.0, like Windows and Linux does.

It is not so much 'support' TPM as it is "includes" a TPM. If the
machine does not have one (and many not so old and older systems do
not) then there is not one present to use in any fashion.

On 12/31/2024 5:00 PM, Stefan Claas wrote:
> echo 'Happy News Year 2025' | ternary
> 2112102022020111101010222211010022112012102120110020100021120220
> 10000111010121200020221000211000220022020
>
> $ echo 'Happy News Year 2025' | ternary | ternary -d
> Happy News Year 2025
>
> (My program works with binary data as well.)
>

Side note, try to get 3-ary roots from the following... It's not that
hard but its fun wrt the results one can reap from it:

https://paulbourke.org/fractals/multijulia

;^)

Stefan Claas <pollux@tilde.club> wrote:
> My old pads program is already updated. It compiled flawlessly for
> many different platforms, including macOS, but I do not know if they
> all support TPM 2.0, like Windows and Linux does.
>
> https://github.com/706f6c6c7578/pads

Looking over your pads program, while you are retreiving true random
numbers from the TPM chip, you are introducing a bias when you use the
random bytes from the TPM to output letters or digits.

Take for example your "letters" arm:

if l {
random, _ := tpm2.GetRandom(rwc, 5)
for m := 0; m < 5; m++ {
fmt.Printf("%c", 'A'+(random[m]%26))
}
}

Now, if I've decoded the awful documentation for the TPM2 module
properly [1] the tpm2.GetRandom call will return five bytes (presumably
unsigned bytes) of random data.

Then, you loop over the five bytes, outputting the letter that
corresponds to ASCII A plus the remainder after dividing the byte by
26. Which is where you introduce a bias.

A byte will have a value from 0 to 255, for 256 total values.

But 26 does not evenly divide 256. 256/26 ~ 9.846

26 divides 256 evenly 9 times, no problem here. That covers values 0
to 233. But for any bytes returned from GetRandom that fall into the
range 234 to 255, you have only 21 possible values that can return from
the modulo. So your remainder will be only 0 through 21. You'll never
get 22 through 25 out, because there is not enough numeric range in the
"tail" to return 22 through 25 from the modulo. So for any bytes with
values 234 to 255 from the TPM, you can return A through V but will
never return W, X, Y or Z.

So your resulting letters will have a bias for A through V.

The fix is easy, first check the value of the byte you are about to
use, and if it happens to be greater than 233, throw that byte away and
pull another from the TPM.

You produce the same bias for your digits, since an unsigned three byte
value is 2^24 = 16_777_216 but that is not evenly divisible by 100000.
So you'll have a range of "low numbers" that are slightly more likely
to occur (a bias) than they should if they were truly random.

This is one of the many examples where it is very easy to mess up the
implementation of a crypto system such that a crack is left for a
skilled cryptographer to exploit.

[1] it is actually worse than awful, it is non-existant, but that seems
to be a normal given aspect for most of the 'newfangled' languages
out there, no documentation in sight anywhere

Rich wrote:
> Stefan Claas <pollux@tilde.club> wrote:
> > My old pads program is already updated. It compiled flawlessly for
> > many different platforms, including macOS, but I do not know if they
> > all support TPM 2.0, like Windows and Linux does.
> >
> > https://github.com/706f6c6c7578/pads
>
> Looking over your pads program, while you are retreiving true random
> numbers from the TPM chip, you are introducing a bias when you use the
> random bytes from the TPM to output letters or digits.
>
> Take for example your "letters" arm:
>
> if l {
> random, _ := tpm2.GetRandom(rwc, 5)
> for m := 0; m < 5; m++ {
> fmt.Printf("%c", 'A'+(random[m]%26))
> }
> }
>
> Now, if I've decoded the awful documentation for the TPM2 module
> properly [1] the tpm2.GetRandom call will return five bytes (presumably
> unsigned bytes) of random data.
>
> Then, you loop over the five bytes, outputting the letter that
> corresponds to ASCII A plus the remainder after dividing the byte by
> 26. Which is where you introduce a bias.
>
> A byte will have a value from 0 to 255, for 256 total values.
>
> But 26 does not evenly divide 256. 256/26 ~ 9.846
>
> 26 divides 256 evenly 9 times, no problem here. That covers values 0
> to 233. But for any bytes returned from GetRandom that fall into the
> range 234 to 255, you have only 21 possible values that can return from
> the modulo. So your remainder will be only 0 through 21. You'll never
> get 22 through 25 out, because there is not enough numeric range in the
> "tail" to return 22 through 25 from the modulo. So for any bytes with
> values 234 to 255 from the TPM, you can return A through V but will
> never return W, X, Y or Z.
>
> So your resulting letters will have a bias for A through V.
>
> The fix is easy, first check the value of the byte you are about to
> use, and if it happens to be greater than 233, throw that byte away and
> pull another from the TPM.
>
> You produce the same bias for your digits, since an unsigned three byte
> value is 2^24 = 16_777_216 but that is not evenly divisible by 100000.
> So you'll have a range of "low numbers" that are slightly more likely
> to occur (a bias) than they should if they were truly random.
>
> This is one of the many examples where it is very easy to mess up the
> implementation of a crypto system such that a crack is left for a
> skilled cryptographer to exploit.
>
>
> [1] it is actually worse than awful, it is non-existant, but that seems
> to be a normal given aspect for most of the 'newfangled' languages
> out there, no documentation in sight anywhere

Excellent observation! Thanks a lot, much appreciated! The Go code and
binaries are now updated, according to your suggestions.

--
Regards
Stefan

Chris M. Thomasson wrote:
> On 12/31/2024 5:00 PM, Stefan Claas wrote:
> > echo 'Happy News Year 2025' | ternary
> > 2112102022020111101010222211010022112012102120110020100021120220
> > 10000111010121200020221000211000220022020
> >
> > $ echo 'Happy News Year 2025' | ternary | ternary -d
> > Happy News Year 2025
> >
> > (My program works with binary data as well.)
> >
>
> Side note, try to get 3-ary roots from the following... It's not that
> hard but its fun wrt the results one can reap from it:
>
> https://paulbourke.org/fractals/multijulia

Nice, but I do no longer do Computer Graphics.

--
Regards
Stefan