• fun with nonces

    From Stefan Claas@21:1/5 to All on Thu Jul 4 17:47:06 2024
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Rich@21:1/5 to Stefan Claas on Fri Jul 5 04:13:16 2024
    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".

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Stefan Claas@21:1/5 to Rich on Fri Jul 5 14:23:41 2024
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Rich@21:1/5 to Stefan Claas on Fri Jul 5 16:02:57 2024
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Stefan Claas@21:1/5 to Rich on Fri Jul 5 17:33:30 2024
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Chax Plore@21:1/5 to Stefan Claas on Fri Jul 5 19:40:44 2024
    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------

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Stefan Claas@21:1/5 to Chax Plore on Fri Jul 5 19:07:09 2024
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Rich@21:1/5 to Stefan Claas on Fri Jul 5 19:46:51 2024
    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)?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Rich@21:1/5 to Stefan Claas on Fri Jul 5 19:44:10 2024
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Stefan Claas@21:1/5 to Rich on Fri Jul 5 20:06:53 2024
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Stefan Claas@21:1/5 to Rich on Fri Jul 5 20:17:46 2024
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Stefan Claas@21:1/5 to Chris M. Thomasson on Fri Jul 5 20:46:33 2024
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Stefan Claas@21:1/5 to Stefan Claas on Sat Jul 6 08:22:03 2024
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Stefan Claas@21:1/5 to Chris M. Thomasson on Sun Jul 7 21:01:49 2024
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Stefan Claas@21:1/5 to Stefan Claas on Mon Jul 8 18:35:12 2024
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Stefan Claas@21:1/5 to Stefan Claas on Tue Jul 9 14:20:45 2024
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Stefan Claas@21:1/5 to Stefan Claas on Thu Aug 22 20:44:56 2024
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Stefan Claas@21:1/5 to Stefan Claas on Tue Nov 12 20:28:23 2024
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)