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!

--
Regards
Stefan

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

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

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

--
Regards
Stefan

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

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

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

--
Regards
Stefan

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?

On 2024-07-04 19:47, Stefan Claas wrote:
> 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!
>

--

-----BEGIN PGP PUBLIC KEY FINGERPRINT-----
5745 807C 2B82 14D8 AB06 422C 8876 5DFC 2A51 778C
------END PGP PUBLIC KEY FINGERPRINT------

Chax Plore wrote:
>
> 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+.
> 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)?

--
Regards
Stefan

Stefan Claas <pollux@tilde.club> wrote:
> Rich wrote:
>> Stefan Claas <pollux@tilde.club> wrote:
>> > Rich wrote:
>> > > Stefan Claas <pollux@tilde.club> wrote:
>> > > > 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 <pollux@tilde.club> wrote:
> Chax Plore wrote:
>>
>> 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+.
>
>> 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)?

Rich wrote:
> Stefan Claas <pollux@tilde.club> wrote:
> > Chax Plore wrote:
> > >
> > > 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+.
> >
> > > 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)?

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

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

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

--
Regards
Stefan

On 7/4/2024 10:47 AM, Stefan Claas wrote:
> 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.

Chris M. Thomasson wrote:
> On 7/4/2024 10:47 AM, Stefan Claas wrote:
> > 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.

--
Regards
Stefan

Stefan Claas wrote:
> 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.

--
Regards
Stefan

On 7/5/2024 1:46 PM, Stefan Claas wrote:
> Chris M. Thomasson wrote:
>> On 7/4/2024 10:47 AM, Stefan Claas wrote:
>>> 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?

Chris M. Thomasson wrote:
> On 7/5/2024 1:46 PM, Stefan Claas wrote:

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

--
Regards
Stefan

Stefan Claas wrote:
> 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.

--
Regards
Stefan

Stefan Claas wrote:

> 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

--
Regards
Stefan

Stefan Claas wrote:
> Stefan Claas wrote:
> > 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.
>

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

--
Regards
Stefan

Stefan Claas wrote:

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

--
Regards
Stefan