You thoughts please, gentlemen.

Let's say you travel and do not want to store your secret hex key on your
device and recreate it from memory.

What do you think about this proposal?

$ printf '%x' $(date -u -d '1979-01-01 12:34:56' +%s) $(date ...) 4 or 8 times.

One has to remember only the dates (times are optional) and then simply run the
one liner.

The encryption software can be downloaded when one arrives at his destination.

--
Regards
Stefan

Stefan Claas wrote:

> You thoughts please, gentlemen.
>
> Let's say you travel and do not want to store your secret hex key on your
> device and recreate it from memory.
>
> What do you think about this proposal?
>
> $ printf '%x' $(date -u -d '1979-01-01 12:34:56' +%s) $(date ...) 4 or 8 times.
>
> One has to remember only the dates (times are optional) and then simply run the
> one liner.

And use that as a seed for Argon2id key creation.

>
> The encryption software can be downloaded when one arrives at his destination.
>

--
Regards
Stefan

Stefan Claas wrote:

> Stefan Claas wrote:
>
> > You thoughts please, gentlemen.
> >
> > Let's say you travel and do not want to store your secret hex key on your
> > device and recreate it from memory.
> >
> > What do you think about this proposal?
> >
> > $ printf '%x' $(date -u -d '1979-01-01 12:34:56' +%s) $(date ...) 4 or 8 times.
> >
> > One has to remember only the dates (times are optional) and then simply run the
> > one liner.
>
> And use that as a seed for Argon2id key creation.
>
> >
> > The encryption software can be downloaded when one arrives at his destination.
> >
>

I think diceware passwords with Argon2id are the solution, because one can
recreate the Argon2id hex key with with the memorized diceware passphrase. :-)

--
Regards
Stefan

Stefan Claas wrote:
> I think diceware passwords with Argon2id are the solution, because one can
> recreate the Argon2id hex key with with the memorized diceware passphrase. :-)
>

For German speaking readers:

https://github.com/dys2p/wordlists-de

--
Regards
Stefan

Stefan Claas <pollux@tilde.club> wrote:
> You thoughts please, gentlemen.
>
> Let's say you travel and do not want to store your secret hex key on
> your device and recreate it from memory.
>
> What do you think about this proposal?
>
> $ printf '%x' $(date -u -d '1979-01-01 12:34:56' +%s) $(date ...) 4
> or 8 times.
>
> One has to remember only the dates (times are optional) and then
> simply run the one liner.

While it is likely one might remember four or eight random dates more
easily than a 16 or 32 character hex key, there's still the problem of
remembering 4 or 8 random dates. Most folks remember "dates" because
something of importance happened on said date, and not just "a date",
so this might make the effort easier, but it is still possible to
'forget' one of the four, or eight, dates.

Given that the "dates" chunk the long string into "blocks", it might be
reasonable to use an erasure coding algorithm on the "blocks", and append
one or more blocks (i.e., dates) that are the erasure codes. Then
forgetting (or misremembering) one or two of the dates might still
allow for recovery of the original key (or at least allow for detection
of a misremembering situation).

Rich wrote:
> Given that the "dates" chunk the long string into "blocks", it might be
> reasonable to use an erasure coding algorithm on the "blocks", and append
> one or more blocks (i.e., dates) that are the erasure codes. Then
> forgetting (or misremembering) one or two of the dates might still
> allow for recovery of the original key (or at least allow for detection
> of a misremembering situation).

Well, I guess this would then need a program to handle, right?

My Idea is to use no program for that, so that no evidence can be
found on the device, in case someone is looking at it.

--
Regards
Stefan

Stefan Claas <pollux@tilde.club> wrote:
> Rich wrote:
>
>> Given that the "dates" chunk the long string into "blocks", it might be
>> reasonable to use an erasure coding algorithm on the "blocks", and append
>> one or more blocks (i.e., dates) that are the erasure codes. Then
>> forgetting (or misremembering) one or two of the dates might still
>> allow for recovery of the original key (or at least allow for detection
>> of a misremembering situation).
>
> Well, I guess this would then need a program to handle, right?

Yes, but you also need a program to handle the conversion from dates to
hex and back. Granted, few would suspect that the "date" command was
used to convert the dates back into a 'key'.

> My Idea is to use no program for that, so that no evidence can be
> found on the device, in case someone is looking at it.

It could be a generic erasure coding program, and the exact parameters
(block size, amount of redundancy, etc.) are remembered and specified
only when it is run to 'check' the output. Then it would, presumably,
be no more suspicious than the 'date' command itself (other than what
suspicion might be raised by the fact that most OS'es don't ship with
an erasure coder by default).

On Tue, 18 Jun 2024 19:42:08 -0000 (UTC), Rich wrote:

> only when it is run to 'check' the output. Then it would, presumably,
> be no more suspicious than the 'date' command itself (other than what
> suspicion might be raised by the fact that most OS'es don't ship with an
> erasure coder by default).

But many (most?) Linux distributions ship with Python (or it's easy to
acquire), which can be used to obfuscate such things.

>>> import hashlib as h
>>> h.sha256(b'this is my secret key I DO remember').hexdigest()[::-1]
'6a8aabb884123762ccf20e6445fddfe58446ba47b4622a315b7d22bae992f965'

So little code you don't have to save anything to disk. The secret key is
almost longer. :)

--
Cri-Cri

Rich wrote:

> Stefan Claas <pollux@tilde.club> wrote:

> > Well, I guess this would then need a program to handle, right?
>
> Yes, but you also need a program to handle the conversion from dates to
> hex and back. Granted, few would suspect that the "date" command was
> used to convert the dates back into a 'key'.

And in case people are looking at bash's history, for to many date
usages, I have a 'del' command in my .bashrc. :-)

alias del=">~/.bash_history;history -cw;"

> > My Idea is to use no program for that, so that no evidence can be
> > found on the device, in case someone is looking at it.
>
> It could be a generic erasure coding program, and the exact parameters
> (block size, amount of redundancy, etc.) are remembered and specified
> only when it is run to 'check' the output. Then it would, presumably,
> be no more suspicious than the 'date' command itself (other than what
> suspicion might be raised by the fact that most OS'es don't ship with
> an erasure coder by default).

I guess, instead of an erasure program, I will only use date and put
the output in my argon2id program, for key generation, which also has
the option to overwrite the clipboard.

--
Regards
Stefan

Stefan Claas <pollux@tilde.club> wrote:
> Rich wrote:
>
>> Stefan Claas <pollux@tilde.club> wrote:
>
>> > Well, I guess this would then need a program to handle, right?
>>
>> Yes, but you also need a program to handle the conversion from dates to
>> hex and back. Granted, few would suspect that the "date" command was
>> used to convert the dates back into a 'key'.
>
> And in case people are looking at bash's history, for to many date
> usages, I have a 'del' command in my .bashrc. :-)
>
> alias del=">~/.bash_history;history -cw;"

Yes, you would want to clear the history, or configure bash to not save
those specific invocations in the first place.

>> > My Idea is to use no program for that, so that no evidence can be
>> > found on the device, in case someone is looking at it.
>>
>> It could be a generic erasure coding program, and the exact parameters
>> (block size, amount of redundancy, etc.) are remembered and specified
>> only when it is run to 'check' the output. Then it would, presumably,
>> be no more suspicious than the 'date' command itself (other than what
>> suspicion might be raised by the fact that most OS'es don't ship with
>> an erasure coder by default).
>
> I guess, instead of an erasure program, I will only use date and put
> the output in my argon2id program, for key generation, which also has
> the option to overwrite the clipboard.

Which means you /do/ have another program available, that could be
'looked for'....

Cri-Cri <cri@cri.cri.invalid> wrote:
> On Tue, 18 Jun 2024 19:42:08 -0000 (UTC), Rich wrote:
>
>> only when it is run to 'check' the output. Then it would, presumably,
>> be no more suspicious than the 'date' command itself (other than what
>> suspicion might be raised by the fact that most OS'es don't ship with an
>> erasure coder by default).
>
> But many (most?) Linux distributions ship with Python (or it's easy to
> acquire), which can be used to obfuscate such things.
>
>>>> import hashlib as h
>>>> h.sha256(b'this is my secret key I DO remember').hexdigest()[::-1]
> '6a8aabb884123762ccf20e6445fddfe58446ba47b4622a315b7d22bae992f965'
>
> So little code you don't have to save anything to disk. The secret key is
> almost longer. :)

Also true, and a way to convert something potentially more memerable
than a set of random dates into a 'key'.

And so long as one's python REPL does not save history (or you turn off
history before running the above) you leave no trace behind.

Rich wrote:

> > I guess, instead of an erasure program, I will only use date and put
> > the output in my argon2id program, for key generation, which also has
> > the option to overwrite the clipboard.
>
> Which means you /do/ have another program available, that could be
> 'looked for'....

Well, I am starting to put my binaries also on GitHub, in the
respective repositories. That allows one then to download the
programs, for temporary usage.

--
Regards
Stefan

On Tue, 18 Jun 2024 20:06:21 -0000 (UTC), Rich wrote:

> And so long as one's python REPL does not save history (or you turn off
> history before running the above) you leave no trace behind.

Perhaps try something like PuppyLinux that I think still keep a version
that only runs in RAM around. You can install it on a drive, but one of
its more interesting features was that RAM thing.

There are other systems out there, equally small, or even smaller:
http://tinycorelinux.net/ - not sure how old it is, it's like English
speaking people who own web sites have some general allergy towards
mentioning a date and when they do, it's in some weird, impossible to sort
as text format with characters that on many systems are illegal to use for
file names. Really useful. At the bottom of the front page it says 2008,
but I don't think that's accurate.

--
Cri-Cri

On Tue, 18 Jun 2024 22:01:19 +0200, Stefan Claas wrote:

> alias del=">~/.bash_history;history -cw;"

Can't you stop Bash from ever creating a history?

https://www.cyberciti.biz/faq/disable-bash-shell-history-linux/

--
Cri-Cri

On Tue, 18 Jun 2024 22:10:44 +0200, Stefan Claas wrote:

> Well, I am starting to put my binaries also on GitHub, in the respective
> repositories. That allows one then to download the programs, for
> temporary usage.

Or perhaps install KeePassXC that can use a binary file as part of a
complete key, some image somewhere, like a company logo, an mp3 file or
whatever. Store your GPG private key in a KeePassXC container and lock it
with a long key and that binary file.

Then again, if you are a wannabe spy, you of course won't have any
knowledge about neither KeePassXC nor linux.

--
Cri-Cri

Cri-Cri <cri@cri.cri.invalid> wrote:
>it's like English speaking people who own web sites have some general
>allergy towards mentioning a date

It's not just "english speaking people". This mentality seems to
perfuse across the entire web ecosystem. Something about the relative
/ease/ of putting up a web page causes by far too many of those people
to omit publication dates from anywhere on their page(s).

Stefan Claas <pollux@tilde.club> wrote:
> Rich wrote:
>
>> > I guess, instead of an erasure program, I will only use date and
>> > put the output in my argon2id program, for key generation, which
>> > also has the option to overwrite the clipboard.
>>
>> Which means you /do/ have another program available, that could be
>> 'looked for'....
>
> Well, I am starting to put my binaries also on GitHub, in the
> respective repositories. That allows one then to download the
> programs, for temporary usage.

In which case, one could do the same with an erasure coding program, to
avoid issues of being "found" with a computing device containing the
program during, say, a border crossing.

Cri-Cri <cri@cri.cri.invalid> wrote:
> On Tue, 18 Jun 2024 22:01:19 +0200, Stefan Claas wrote:
>
>> alias del=">~/.bash_history;history -cw;"
>
> Can't you stop Bash from ever creating a history?
>
> https://www.cyberciti.biz/faq/disable-bash-shell-history-linux/

You can, and for a special purpose system intended for "key access"
doing so is probably the best practice.

Meanwhile, if one is doing key access on a system also used for other,
general purpose purposes, fully disabling history does remove a *very*
useful feature in the general case.

The workaround can be to configure bash to not store commands that
begin with a space:

HISTCONTROL
A colon-separated list of values controlling how
commands are saved on the history list. If the list of
values includes ignorespace, lines which begin with a
space character are not saved in the history list.

Of course then one does have to remember to prefix any command that
should not be saved in history with a space.

On Wed, 19 Jun 2024 02:53:34 -0000 (UTC), Rich wrote:

> It's not just "english speaking people". This mentality seems to
> perfuse across the entire web ecosystem. Something about the relative
> /ease/ of putting up a web page causes by far too many of those people
> to omit publication dates from anywhere on their page(s).

Yes, maybe you're right. I read maybe 95% English web stuff so that's why
I notice them more.

--
Cri-Cri

Cri-Cri wrote:

> On Tue, 18 Jun 2024 22:10:44 +0200, Stefan Claas wrote:
>
> > Well, I am starting to put my binaries also on GitHub, in the respective
> > repositories. That allows one then to download the programs, for
> > temporary usage.
>
> Or perhaps install KeePassXC that can use a binary file as part of a
> complete key, some image somewhere, like a company logo, an mp3 file or
> whatever. Store your GPG private key in a KeePassXC container and lock it
> with a long key and that binary file.

I must admit I can't follow you, nor do I use GPG (I use modern 'age',
available at GitHub :-)).

In case of my GitHub binaries. Argon2id is stored there, so users can
then use, under Windows, the program along with a an additional download
of GNU's coreutils 'date', for Windows, to get an even stronger encryption
key to memorize, than with 'date' only.

--
Regards
Stefan

On 6/18/2024 6:55 AM, Stefan Claas wrote:
> You thoughts please, gentlemen.
>
> Let's say you travel and do not want to store your secret hex key on your
> device and recreate it from memory.
>
> What do you think about this proposal?
>
> $ printf '%x' $(date -u -d '1979-01-01 12:34:56' +%s) $(date ...) 4 or 8 times.
>
> One has to remember only the dates (times are optional) and then simply run the
> one liner.
>
> The encryption software can be downloaded when one arrives at his destination.
>

Generate a hex key from a password? It seems like my site can do it:

http://fractallife247.com/test/hmac_cipher/ver_0_0_0_1?ct_hmac_cipher=2bf63f8ee90dfed997b115aa711600c45a8212a1e35f4f75ccfa36ee459b3fedd8b5f477ebb8871dd94025e7731f39cf7650f864fd6d5ce6908bb2609f96e81a413ccf40b33380a569155cb79612def387c76dd1ae436bcb4fb8c9b959be255708d020d559e07492ba24aae3705ba700a5d9c857418a0050d9ad5935efbfc36b895329cabeacbc7cefdee04834b4d392e50501c55587361bd6ca7337083fcd16ddf95d50072ea61cf2aaeb45d4d676abf93d39ad0a386399d55f2d0dba6be91521068f1120573e96aa1d81362e62f91bf88f63fe159175c13a1abec4184aae1cadfe2e18be27cac0fbefbae0c57cec531bc71e8a86d0f15a727e98bafe0239c5fd06a250e7f6

It encrypts a key using the default password. The key is generated using
the same program. This example basically generates a key using the
default password, then encrypts said key using a different password.

Everybody can decrypt the generated key because the ciphertext in the
link uses the default password:

https://i.ibb.co/BybrYDw/image.png

The plaintext is:

A key:

f65952b125ba6860e21aef9c55e69e0612b153e5fd2599ac00b67945f9bec7563d5edf8bf9fa0db27aeb78b0c8f40f0a6a69b2cd720d59ecc73a01c1ccad0933cfe9e014dda35db6eaba760c9dbdff0f4ad24c5b702baab8e225189179b8bd

Chris M. Thomasson wrote:

> On 6/18/2024 6:55 AM, Stefan Claas wrote:
> > You thoughts please, gentlemen.
> >
> > Let's say you travel and do not want to store your secret hex key on your
> > device and recreate it from memory.
> >
> > What do you think about this proposal?
> >
> > $ printf '%x' $(date -u -d '1979-01-01 12:34:56' +%s) $(date ...) 4 or 8 times.
> >
> > One has to remember only the dates (times are optional) and then simply run the
> > one liner.
> >
> > The encryption software can be downloaded when one arrives at his destination.
> >
>
> Generate a hex key from a password? It seems like my site can do it:
>
> http://fractallife247.com/test/hmac_cipher/ver_0_0_0_1?ct_hmac_cipher=2bf63f8ee90dfed997b115aa711600c45a8212a1e35f4f75ccfa36ee459b3fedd8b5f477ebb8871dd94025e7731f39cf7650f864fd6d5ce6908bb2609f96e81a413ccf40b33380a569155cb79612def387c76dd1ae436bcb4fb8c9b959be255708d020d559e07492ba24aae3705ba700a5d9c857418a0050d9ad5935efbfc36b895329cabeacbc7cefdee04834b4d392e50501c55587361bd6ca7337083fcd16ddf95d50072ea61cf2aaeb45d4d676abf93d39ad0a386399d55f2d0dba6be91521068f1120573e96aa1d81362e62f91bf88f63fe159175c13a1abec4184aae1cadfe2e18be27cac0fbefbae0c57cec531bc71e8a86d0f15a727e98bafe0239c5fd06a250e7f6
>
> It encrypts a key using the default password. The key is generated using
> the same program. This example basically generates a key using the
> default password, then encrypts said key using a different password.
>
> Everybody can decrypt the generated key because the ciphertext in the
> link uses the default password:
>
> https://i.ibb.co/BybrYDw/image.png
>
> The plaintext is:
>
> A key:
>
> f65952b125ba6860e21aef9c55e69e0612b153e5fd2599ac00b67945f9bec7563d5edf8bf9fa0db27aeb78b0c8f40f0a6a69b2cd720d59ecc73a01c1ccad0933cfe9e014dda35db6eaba760c9dbdff0f4ad24c5b702baab8e225189179b8bd

Your site says it does key generation from 64 random bytes. How do you remember the key
when traveling, with no device? Or how can you trust your site, when your are on annual leave, out of your country, and some bad boy customized your site?

--
Regards
Stefan

Cri-Cri <cri@cri.cri.invalid> wrote:
> On Wed, 19 Jun 2024 02:53:34 -0000 (UTC), Rich wrote:
>
>> It's not just "english speaking people". This mentality seems to
>> perfuse across the entire web ecosystem. Something about the relative
>> /ease/ of putting up a web page causes by far too many of those people
>> to omit publication dates from anywhere on their page(s).
>
> Yes, maybe you're right. I read maybe 95% English web stuff so that's why
> I notice them more.

Agreed, English is the majority language, so in sheer numbers there
will be more that omit dates, but the "omission" itself I believe
occurs everywhere.

And, sadly, it even happens with websites that *should* know better,
i.e., the traditional newspaper websites far too often have no dates on
their articles on the web, meanwhile for their legacy paper they date
each physical paper as of the day it was published.

Stefan Claas <pollux@tilde.club> wrote:
> Chris M. Thomasson wrote:
>> Generate a hex key from a password? It seems like my site can do it:
>>
>> http://fractallife247.com/test/hmac_cipher/ver_0_0_0_1?ct_hmac_cipher=2bf63f8ee90dfed997b115aa711600c45a8212a1e35f4f75ccfa36ee459b3fedd8b5f477ebb8871dd94025e7731f39cf7650f864fd6d5ce6908bb2609f96e81a413ccf40b33380a569155cb79612def387c76dd1ae436bcb4fb8c9b959be255708d020d559e07492ba24aae3705ba700a5d9c857418a0050d9ad5935efbfc36b895329cabeacbc7cefdee04834b4d392e50501c55587361bd6ca7337083fcd16ddf95d50072ea61cf2aaeb45d4d676abf93d39ad0a386399d55f2d0dba6be91521068f1120573e96aa1d81362e62f91bf88f63fe159175c13a1abec4184aae1cadfe2e18be27cac0fbefbae0c57cec531bc71e8a86d0f15a727e98bafe0239c5fd06a250e7f6
>>
>> It encrypts a key using the default password. The key is generated
>> using the same program. This example basically generates a key
>> using the default password, then encrypts said key using a different
>> password.
>>
>> Everybody can decrypt the generated key because the ciphertext in
>> the link uses the default password:
>>
>> https://i.ibb.co/BybrYDw/image.png
>>
>> The plaintext is:
>>
>> A key:
>>
>> f65952b125ba6860e21aef9c55e69e0612b153e5fd2599ac00b67945f9bec7563d5edf8bf9fa0db27aeb78b0c8f40f0a6a69b2cd720d59ecc73a01c1ccad0933cfe9e014dda35db6eaba760c9dbdff0f4ad24c5b702baab8e225189179b8bd
>
> Your site says it does key generation from 64 random bytes. How do
> you remember the key when traveling, with no device?

> Or how can you trust your site, when your are on annual leave, out of
> your country, and some bad boy customized your site?

A valid question -- and one that *also* applies to your argon2id on
github. How can you be sure that some cracker did not change the
argon2id present there while you are away on holiday.

Or, how can you trust that a github/microsoft insider with admin level
access did not swap out your good argon2id with a malicious argon2id.

Or that a three letter agency, having taken interest in you for some
reason, has not gotten a secret court order to swap the argon2id with a
cracked one, and included a court ordered gag to prevent
github/microsoft from informing you of the swap?

On 18/06/2024 14:55, Stefan Claas wrote:
> You thoughts please, gentlemen.
>
> Let's say you travel and do not want to store your secret hex key on your
> device and recreate it from memory.
>
> What do you think about this proposal?
>
> $ printf '%x' $(date -u -d '1979-01-01 12:34:56' +%s) $(date ...) 4 or 8 times.
>
> One has to remember only the dates (times are optional) and then simply run the
> one liner.
>
> The encryption software can be downloaded when one arrives at his destination.
>

Pravda - well, Pravda - Pravda said: (Russian double-talk) It stinks.

Dates mostly come in 19xx or 20xx sizes, so those 19.. or 20.. digits
are guessable. The 0 in the month 01 (I am using month first) is mostly
an 0, or else it is a 1. The 0 of the date is either 0,1,2 or 3, so the
entropy is lower.

Plus people will use dates they remember - the Moon landing, their
birthdays, their children's birthdays, and so on.

And remembering the dates and the order is, to be pernickety, hard.

Peter Fairbrother