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
https://github.com/stefanclaas/nfs
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.
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.
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!
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?
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)?
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.
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)?
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.
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.
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
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?
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
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 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.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 493 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 193:22:30 |
| Calls: | 9,707 |
| Calls today: | 2 |
| Files: | 13,740 |
| Messages: | 6,180,251 |