| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 43 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 96:09:42 |
| Calls: | 290 |
| Files: | 904 |
| Messages: | 76,426 |
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.)
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
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).
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.
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
Of course, this just brings to the front the OTP key distribution and
key reuse problems.
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
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).
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. :-)
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.
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.
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.
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
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.
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.
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.
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.
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
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
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