fun with nonces

[Stefan Claas]

Let's assume Bob travels a lot and he wishes to
communicate encrypted with Alice, while using an
encryption program which uses a nonce as additional
input parameter.

He does not need to send Alice the nonces, once he
arrived, because they both have a shared secret.
Alice and Bob can generate them by themselves, no
matter what timezone they are in and the nonces will
be random and can be re-generated with the same values
again, per day.

https://github.com/stefanclaas/nfs

I Have to do a README which explains this scenario
a bit. Hope you like the idea!

[Rich]

Post by Stefan Claas
He does not need to send Alice the nonces, once he
arrived, because they both have a shared secret.
Alice and Bob can generate them by themselves, no
matter what timezone they are in and the nonces will
be random and can be re-generated with the same values

They cannot be simultaneously "random" and be capable of being
"re-generated with the same values".

At best, they are psudeo-random. And, looking over the code, indeed,
they are generated from a psudeo-random generator, go's 'rand'.

Post by Stefan Claas
https://github.com/stefanclaas/nfs

Not the best choice in acronym, as 'nfs' is already quite well known in
tech circles as "Network File System".

[Stefan Claas]

Post by Rich

Post by Stefan Claas
He does not need to send Alice the nonces, once he
arrived, because they both have a shared secret.
Alice and Bob can generate them by themselves, no
matter what timezone they are in and the nonces will
be random and can be re-generated with the same values

They cannot be simultaneously "random" and be capable of being
"re-generated with the same values".
At best, they are psudeo-random. And, looking over the code, indeed,
they are generated from a psudeo-random generator, go's 'rand'.

It uses now xorshift128+ instead of math.rand, to have a 128bit
seed instead of 64bit.

Post by Rich

Post by Stefan Claas
https://github.com/stefanclaas/nfs

Not the best choice in acronym, as 'nfs' is already quite well known in
tech circles as "Network File System".

I know, but I keep the name unless there is a standard Linux or Windows
command with the same name.

[Rich]

Post by Stefan Claas

Post by Rich

Post by Stefan Claas
He does not need to send Alice the nonces, once he
arrived, because they both have a shared secret.
Alice and Bob can generate them by themselves, no
matter what timezone they are in and the nonces will
be random and can be re-generated with the same values

They cannot be simultaneously "random" and be capable of being
"re-generated with the same values".
At best, they are psudeo-random. And, looking over the code, indeed,
they are generated from a psudeo-random generator, go's 'rand'.

It uses now xorshift128+ instead of math.rand, to have a 128bit
seed instead of 64bit.

And it is still psudeo-random.

Post by Stefan Claas

Post by Rich

Post by Stefan Claas
https://github.com/stefanclaas/nfs

Not the best choice in acronym, as 'nfs' is already quite well known in
tech circles as "Network File System".

I know, but I keep the name unless there is a standard Linux or Windows
command with the same name.

That is your choice, just be prepared for lots of confusion on the part
of others.

[Stefan Claas]

Post by Rich

Post by Stefan Claas

Post by Rich

Post by Stefan Claas
He does not need to send Alice the nonces, once he
arrived, because they both have a shared secret.
Alice and Bob can generate them by themselves, no
matter what timezone they are in and the nonces will
be random and can be re-generated with the same values

They cannot be simultaneously "random" and be capable of being
"re-generated with the same values".
At best, they are psudeo-random. And, looking over the code, indeed,
they are generated from a psudeo-random generator, go's 'rand'.

It uses now xorshift128+ instead of math.rand, to have a 128bit
seed instead of 64bit.

And it is still psudeo-random.

And that is perfectly fine, unless of course someone here would show
me a better solution, for using nonces without transmitting them.

[Rich]

Post by Stefan Claas

Post by Rich

Post by Stefan Claas

Post by Rich

Post by Stefan Claas
He does not need to send Alice the nonces, once he
arrived, because they both have a shared secret.
Alice and Bob can generate them by themselves, no
matter what timezone they are in and the nonces will
be random and can be re-generated with the same values

They cannot be simultaneously "random" and be capable of being
"re-generated with the same values".
At best, they are psudeo-random. And, looking over the code, indeed,
they are generated from a psudeo-random generator, go's 'rand'.

It uses now xorshift128+ instead of math.rand, to have a 128bit
seed instead of 64bit.

And it is still psudeo-random.

And that is perfectly fine, unless of course someone here would show
me a better solution, for using nonces without transmitting them.

There is really no need for "shared secret nonces" given standard
encryption modes. The 'nonce' (meaning: "used once" [1]) is present to
randomize a given use of a mode [2] under the same key and plaintext as
a prior use of the same mode/plaintext [3] under the same key. The only
'security' required of the nonce is that eve not be able to predict any
given nonce in advance, which is why they are preferably derived from
true random sources or created by cryptography secure random number
generation algorithms (with a good true randomness seed). But the
security of the encrypted data does not depend upon the actual nonce
being secret to Eve. This is why they are transmitted in the clear at
the start of modes that use a nonce.

But going to great length to generate "secret" nonce's for use by Bob
and Alice is unnecessary.

You appear to be beginning to climb down the same rabbit hole that
Chris quite deeply entered when he was so overly concerned about the
IV/Nonce being in the clear as part of the protocol that Eve got to
examine some years back.


[1] https://www.merriam-webster.com/dictionary/nonce

[2] i.e.: CBC, CFB, CTR, etc)

[3] note that in many encrypted protocols there will often be some
constant plaintext in the underlying message such that without the
randomizing provided by the nonce, a known-plaintext attack can be
performed on those parts of the underlying message.

[Stefan Claas]

Post by Rich

Post by Stefan Claas

Post by Rich

Post by Stefan Claas

Post by Rich

Post by Stefan Claas
He does not need to send Alice the nonces, once he
arrived, because they both have a shared secret.
Alice and Bob can generate them by themselves, no
matter what timezone they are in and the nonces will
be random and can be re-generated with the same values

They cannot be simultaneously "random" and be capable of being
"re-generated with the same values".
At best, they are psudeo-random. And, looking over the code, indeed,
they are generated from a psudeo-random generator, go's 'rand'.

It uses now xorshift128+ instead of math.rand, to have a 128bit
seed instead of 64bit.

And it is still psudeo-random.

And that is perfectly fine, unless of course someone here would show
me a better solution, for using nonces without transmitting them.

There is really no need for "shared secret nonces" given standard
encryption modes. The 'nonce' (meaning: "used once" [1]) is present to
randomize a given use of a mode [2] under the same key and plaintext as
a prior use of the same mode/plaintext [3] under the same key. The only
'security' required of the nonce is that eve not be able to predict any
given nonce in advance, which is why they are preferably derived from
true random sources or created by cryptography secure random number
generation algorithms (with a good true randomness seed). But the
security of the encrypted data does not depend upon the actual nonce
being secret to Eve. This is why they are transmitted in the clear at
the start of modes that use a nonce.

I have read quite a bit about nonce usage and agree, but they can be
also pseudo-random.

Post by Rich
But going to great length to generate "secret" nonce's for use by Bob
and Alice is unnecessary.

Well, known crypto algos don't have to do that, correct! But I like to
use this scheme with Google's Adiantum Encryption, which allows this.

I like Adiantum very much because it is Format Preserving Encryption,
which can be used, besides disk encryption on mobile devices, also for
SMS encryption with feature phones, which is pretty cool and more secure
IMHO than using a smartphone with crypto messengers etc.

Post by Rich
You appear to be beginning to climb down the same rabbit hole that
Chris quite deeply entered when he was so overly concerned about the
IV/Nonce being in the clear as part of the protocol that Eve got to
examine some years back.

No, see above and instead of sending them in advance why not generate
them on the fly, for each day and then use them, without sending, along
with a 256 bit key.

[Chax Plore]

Xorshift is reversible, so if Eve is up to no good, then she can use the
foreknowledge of nonce in bad way (no specific attack in mind, but
nothing in the message should be predictable or "crackable").

I suggest to use HKDF instead to generate the nonce in your scheme,
which I would name "nonce ratchet" instead of confusing "nfs" (I'm just
looking on my NAS console, where I see two volumes mounted as NFS shares).

And If you are already using KKDF, they why not to "ratchet" the whole
key/nonce/iv/salt material this way, if you intend to leave no variables
in plain sight?

Post by Stefan Claas
Let's assume Bob travels a lot and he wishes to
communicate encrypted with Alice, while using an
encryption program which uses a nonce as additional
input parameter.
He does not need to send Alice the nonces, once he
arrived, because they both have a shared secret.
Alice and Bob can generate them by themselves, no
matter what timezone they are in and the nonces will
be random and can be re-generated with the same values
again, per day.
https://github.com/stefanclaas/nfs
I Have to do a README which explains this scenario
a bit. Hope you like the idea!

[Stefan Claas]

Post by Chax Plore
Xorshift is reversible, so if Eve is up to no good, then she can use the
foreknowledge of nonce in bad way (no specific attack in mind, but
nothing in the message should be predictable or "crackable").
I suggest to use HKDF instead to generate the nonce in your scheme,
which I would name "nonce ratchet" instead of confusing "nfs" (I'm just
looking on my NAS console, where I see two volumes mounted as NFS shares).

Thanks for your valuable input, much appreciated! The Program uses now
hkdf, instead of corshift128+.

Post by Chax Plore
And If you are already using KKDF, they why not to "ratchet" the whole
key/nonce/iv/salt material this way, if you intend to leave no variables
in plain sight?

What do you mean (language barrier)?

[Rich]

Post by Chax Plore
Xorshift is reversible, so if Eve is up to no good, then she can use
the foreknowledge of nonce in bad way (no specific attack in mind,
but nothing in the message should be predictable or "crackable").
I suggest to use HKDF instead to generate the nonce in your scheme,
which I would name "nonce ratchet" instead of confusing "nfs" (I'm
just looking on my NAS console, where I see two volumes mounted as
NFS shares).

Thanks for your valuable input, much appreciated! The Program uses
now hkdf, instead of corshift128+.

Post by Chax Plore
And If you are already using KKDF, they why not to "ratchet" the
whole key/nonce/iv/salt material this way, if you intend to leave no
variables in plain sight?

What do you mean (language barrier)?

If I got Chax's meaning properly, the statement is:

Why not use this scheme to generate all of the "key", "nonce", "iv",
and "salt" such that all four change with each new message
(effectively making the four a large 'key' of sorts)?

[Stefan Claas]

Post by Rich

Post by Chax Plore
Xorshift is reversible, so if Eve is up to no good, then she can use
the foreknowledge of nonce in bad way (no specific attack in mind,
but nothing in the message should be predictable or "crackable").
I suggest to use HKDF instead to generate the nonce in your scheme,
which I would name "nonce ratchet" instead of confusing "nfs" (I'm
just looking on my NAS console, where I see two volumes mounted as
NFS shares).

Thanks for your valuable input, much appreciated! The Program uses
now hkdf, instead of corshift128+.

Post by Chax Plore
And If you are already using KKDF, they why not to "ratchet" the
whole key/nonce/iv/salt material this way, if you intend to leave no
variables in plain sight?

What do you mean (language barrier)?

Why not use this scheme to generate all of the "key", "nonce", "iv",
and "salt" such that all four change with each new message
(effectively making the four a large 'key' of sorts)?

Ah, but I only need nonces.

I deleted the repository and created a new one, named nora.
Nora is a female Name and Nora could be a good friend of
Alice and Bob. :-) https://github.com/stefanclaas/nora

[Stefan Claas]

Post by Stefan Claas
I deleted the repository and created a new one, named nora.
Nora is a female Name and Nora could be a good friend of
Alice and Bob. :-) https://github.com/stefanclaas/nora

Optional -b flag added for 'party B', so that when Alice and
Bob would send a message at the same time, using the same nonce
is prevented. With the -b flag the hash value is incremented
by one.

[Chris M. Thomasson]

Post by Stefan Claas
Let's assume Bob travels a lot and he wishes to
communicate encrypted with Alice, while using an
encryption program which uses a nonce as additional
input parameter.
He does not need to send Alice the nonces, once he
arrived, because they both have a shared secret.
Alice and Bob can generate them by themselves, no
matter what timezone they are in and the nonces will
be random and can be re-generated with the same values
again, per day.
https://github.com/stefanclaas/nfs
I Have to do a README which explains this scenario
a bit. Hope you like the idea!

Hopefully the nonces were created by a TRNG such that they cannot be
repeated expect by pure chance... Fair enough?

Every PRNG has a period and a way to set the starting point.

[Stefan Claas]

Post by Chris M. Thomasson

Post by Stefan Claas
Let's assume Bob travels a lot and he wishes to
communicate encrypted with Alice, while using an
encryption program which uses a nonce as additional
input parameter.
He does not need to send Alice the nonces, once he
arrived, because they both have a shared secret.
Alice and Bob can generate them by themselves, no
matter what timezone they are in and the nonces will
be random and can be re-generated with the same values
again, per day.
https://github.com/stefanclaas/nfs
I Have to do a README which explains this scenario
a bit. Hope you like the idea!

Hopefully the nonces were created by a TRNG such that they cannot be
repeated expect by pure chance... Fair enough?
Every PRNG has a period and a way to set the starting point.

Well, they can be also pseudo-random. Mine are deterministic,
based on a passphrase and date while using hkdf.

[Chris M. Thomasson]

Post by Stefan Claas

Post by Chris M. Thomasson

Post by Stefan Claas
Let's assume Bob travels a lot and he wishes to
communicate encrypted with Alice, while using an
encryption program which uses a nonce as additional
input parameter.
He does not need to send Alice the nonces, once he
arrived, because they both have a shared secret.
Alice and Bob can generate them by themselves, no
matter what timezone they are in and the nonces will
be random and can be re-generated with the same values
again, per day.
https://github.com/stefanclaas/nfs
I Have to do a README which explains this scenario
a bit. Hope you like the idea!

Hopefully the nonces were created by a TRNG such that they cannot be
repeated expect by pure chance... Fair enough?
Every PRNG has a period and a way to set the starting point.

Well, they can be also pseudo-random. Mine are deterministic,
based on a passphrase and date while using hkdf.

Can somebody try to get at things where they can gain educated guesses
at your schedule, so to speak?

[Stefan Claas]

Post by Chris M. Thomasson

Post by Stefan Claas

Post by Chris M. Thomasson
Hopefully the nonces were created by a TRNG such that they cannot be
repeated expect by pure chance... Fair enough?
Every PRNG has a period and a way to set the starting point.

Well, they can be also pseudo-random. Mine are deterministic,
based on a passphrase and date while using hkdf.

Can somebody try to get at things where they can gain educated guesses
at your schedule, so to speak?

For the nonce only, without using a cipher, I would say no, because Alice
and Bob have a shared secret, which is used along with a date (only day,
not time and as UTC timezone) and nor Alice or Bob have to send the nonces
to each other, so that encryption and decription, with, for example, my
Adiantum implemention works nicely.

Here is an example: Let's say Bob is in Germany, as of today, with current
time 22:41 CET and he sends an encrypted message with Adiantum now to Alice.
Alice, in the U.S., much earlier time, because of the different timezone,
simply runs nora[1] with Adiantum[2] and can be sure that when she creates
*todays* nonce(s) that the message will decrypt, because of UTC timezone
used in nora.

A sample run with nora looks like this:

$ nora
Usage: -p <password> [-b party B] [-n number of nonces] [-l length of the nonce]
[-s save nonces]

So Bob, as of today and now, runs nora with the shared secret 'test'
and the output will be:

$ nora -p test -n 10
1: 2aba3cbd0f2435c1231d7acd897f33b6 20240707
2: fd1cf73718ace13892282ce1c85079c0 20240707
3: 8c7bb448faeb2bc2886a13e29acd70cc 20240707
4: c8e80e0e6a56a150a6497df6669e0299 20240707
5: 691078499be8e87922a6c5e28f0a80a2 20240707
6: 944214f54301641f0c267f3aaf44d001 20240707
7: 5959b96219a2d6a56b05a04a4ed01b87 20240707
8: ebfc1313981df46d0f3326e7eacdb738 20240707
9: de155347f93107b8367ce0ff8e3f473b 20240707
10: b81c73bcbc173b5e15b597bfeb8e5541 20240707

Bob can re-run nora later and the same nonces will be generated
for today.

Alice, as receiver of the encrypted message, would then reply with
nonces using the -b paramter, to prevent that the same nonce is
used, in case they both would send a message at the same time.

As you can see from the output the hex values, which are not
exchanged, they leave, I would say, no information, about my
schedule.

I believe that this scheme is secure enough when using it,
for example, with Adiantum and allows Alice and Bob not to
worry about nonce creation, which they do not want to send
to each other and it is also easy to use and to understand.

[1] https://github.com/stefanclaas/nora
[2] https:/github.com/stefanclaas/adiantum

[Stefan Claas]

Post by Stefan Claas
I believe that this scheme is secure enough when using it,
for example, with Adiantum and allows Alice and Bob not to
worry about nonce creation, which they do not want to send
to each other and it is also easy to use and to understand.
[1] https://github.com/stefanclaas/nora
[2] https://github.com/stefanclaas/adiantum

A sample run of nora, Adiantum and Argon2id (for a deterministic
256 bit key):

$ argon2id -p test -s test -w key
(a26b1128e1240639f2379b66fc56ea00a0e93e976aade1227cc5b34b38d00a82)

$ nora -p test -n 10 -s
1: ad0cbbf918830532d767c8a480495cdc 20240708
2: 26976ec2d08a91b1db184f40deae2128 20240708
3: e825c6ce7b0a3abd7ccba70035a445c4 20240708
4: 1dcf05c05761384313be893293e05348 20240708
5: 00b601719fe6a69bd3e475177a9d1d8c 20240708
6: ee4eaa08a04ee004228b35f05a24dfc2 20240708
7: 275ce7188f08be7c289fb017dfb7edcf 20240708
8: 2d39733a7336d33f7b806f7a3e79fea6 20240708
9: f7e9275ddba627fc8a48b3ca71ac91e9 20240708
10: 8659306f69634b7127bdf3701c887747 20240708

$ echo -n 'Hi Alice, I arrived today at 06:00 PM.' | adiantum key
n-1 > msg_enc.txt

$ hexdump -Cv msg.txt
00000000 48 69 20 41 6c 69 63 65 2c 20 49 20 61 72 72 69 |Hi Alice, I arri|
00000010 76 65 64 20 74 6f 64 61 79 20 61 74 20 30 36 3a |ved today at 06:|
00000020 30 30 20 50 4d 2e |00 PM.|
00000026

$ hexdump -Cv msg_enc.txt
00000000 d7 74 06 ca 73 bd a2 07 38 cb 80 0a 73 62 79 d6 |.t..s...8...sby.|
00000010 d4 89 96 a5 ff 5e f6 ba 4e 13 e0 a0 93 f8 81 88 |.....^..N.......|
00000020 c0 bb a3 a8 a8 42 |.....B|
00000026

As one can see FPE (Format Preserving Encryption) is pretty cool,
because one can use it with a base26 encoder for SMS messages,
with an old feature phone and a cute GPD MicroPC and does not
need a smartphone, which can be easily compromised with Pegasus etc.

[Stefan Claas]

Post by Stefan Claas
As one can see FPE (Format Preserving Encryption) is pretty cool,
because one can use it with a base26 encoder for SMS messages,
with an old feature phone and a cute GPD MicroPC and does not
need a smartphone, which can be easily compromised with Pegasus etc.

And if used with a burner phone you would have denialable encryption,
when using a Live System, right?

It is even getting better when using above programs with red and sve
to have denialable signing capabilities, when used with a Live Sytem.

https://github.com/stefanclaas/red
https://github.com/stefanclaas/sve

[Stefan Claas]

Post by Stefan Claas

Post by Stefan Claas
I believe that this scheme is secure enough when using it,
for example, with Adiantum and allows Alice and Bob not to
worry about nonce creation, which they do not want to send
to each other and it is also easy to use and to understand.
[1] https://github.com/stefanclaas/nora
[2] https://github.com/stefanclaas/adiantum

A sample run of nora, Adiantum and Argon2id (for a deterministic
$ argon2id -p test -s test -w key
(a26b1128e1240639f2379b66fc56ea00a0e93e976aade1227cc5b34b38d00a82)
$ nora -p test -n 10 -s
1: ad0cbbf918830532d767c8a480495cdc 20240708
2: 26976ec2d08a91b1db184f40deae2128 20240708
3: e825c6ce7b0a3abd7ccba70035a445c4 20240708
4: 1dcf05c05761384313be893293e05348 20240708
5: 00b601719fe6a69bd3e475177a9d1d8c 20240708
6: ee4eaa08a04ee004228b35f05a24dfc2 20240708
7: 275ce7188f08be7c289fb017dfb7edcf 20240708
8: 2d39733a7336d33f7b806f7a3e79fea6 20240708
9: f7e9275ddba627fc8a48b3ca71ac91e9 20240708
10: 8659306f69634b7127bdf3701c887747 20240708
$ echo -n 'Hi Alice, I arrived today at 06:00 PM.' | adiantum key
n-1 > msg_enc.txt
$ hexdump -Cv msg.txt
00000000 48 69 20 41 6c 69 63 65 2c 20 49 20 61 72 72 69 |Hi Alice, I arri|
00000010 76 65 64 20 74 6f 64 61 79 20 61 74 20 30 36 3a |ved today at 06:|
00000020 30 30 20 50 4d 2e |00 PM.|
00000026
$ hexdump -Cv msg_enc.txt
00000000 d7 74 06 ca 73 bd a2 07 38 cb 80 0a 73 62 79 d6 |.t..s...8...sby.|
00000010 d4 89 96 a5 ff 5e f6 ba 4e 13 e0 a0 93 f8 81 88 |.....^..N.......|
00000020 c0 bb a3 a8 a8 42 |.....B|
00000026
As one can see FPE (Format Preserving Encryption) is pretty cool,
because one can use it with a base26 encoder for SMS messages,
with an old feature phone and a cute GPD MicroPC and does not
need a smartphone, which can be easily compromised with Pegasus etc.

An optional -salt parameter with PBKDF2 is now available in nora.

[Stefan Claas]

Post by Stefan Claas
An optional -salt parameter with PBKDF2 is now available in nora.

An -r parameter is added, so that you can set a date, which is IMHO
very important, when using postal mail and the encrypted message(s)
arrive a couple of days later.