Memorizing a 128 bit / 256 bit hex key

[Stefan Claas]

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.

[Stefan Claas]

Post by Stefan Claas
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.

Post by Stefan Claas
The encryption software can be downloaded when one arrives at his destination.

[Stefan Claas]

Post by Stefan Claas

Post by Stefan Claas
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.

Post by Stefan Claas
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. :-)

[Stefan Claas]

Post by Stefan Claas
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

[Peter Fairbrother]

Post by Stefan Claas

Post by Stefan Claas

Post by Stefan Claas
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.

Post by Stefan Claas
The encryption software can be downloaded when one arrives at his destination.

Hmm, from where? Threat analysis?

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

Much better.

Both diceware and argon2id can be improved on, but generally that would
mostly work.


Peter Fairbrother

bored, just got out of hospital, and laid up with bad knee

[Stefan Claas]

Post by Peter Fairbrother

Post by Stefan Claas

Post by Stefan Claas

Post by Stefan Claas
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.

Post by Stefan Claas
The encryption software can be downloaded when one arrives at his destination.

Hmm, from where? Threat analysis?

Well, for example from GitHub. Prior departure you write down on a piece of paper,
which you carry in your wallet, the shasum and on arrival you download and compare
the shasum.

Post by Peter Fairbrother

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

Much better.
Both diceware and argon2id can be improved on, but generally that would
mostly work.
Peter Fairbrother
bored, just got out of hospital, and laid up with bad knee

[Peter Fairbrother]

Post by Stefan Claas

Post by Stefan Claas
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.

But Izvestia! Izvestia said: (Russian double-talk) It stinks.


Entropy is considerably lower than 128 bits, probably around 30 bits at
a swag..


Peter Fairbrother

[Stefan Claas]

Post by Peter Fairbrother

Post by Stefan Claas

Post by Stefan Claas
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.

But Izvestia! Izvestia said: (Russian double-talk) It stinks.
Entropy is considerably lower than 128 bits, probably around 30 bits at
a swag..

Thanks for pointing that out.

[Rich]

Post by Stefan Claas
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).

[Stefan Claas]

Post by Rich
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.

[Rich]

Post by Stefan Claas

Post by Rich
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'.

Post by Stefan Claas
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).

[Cri-Cri]

Post by Rich
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.

Post by Rich

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

[Rich]

Post by Cri-Cri

Post by Rich
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.

Post by Rich

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.

[Cri-Cri]

Post by Rich
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.

[Rich]

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

[Cri-Cri]

Post by Rich
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.

[Rich]

Post by Cri-Cri

Post by Rich
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.

[Cri-Cri]

Post by Rich
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.

I suppose one could pester them with questions on a daily basis, until
they learned that it would be easier to put the date on the page already
from day one. :)

Then again, I also see a trend that companies that are represented on the
web, these days seldom provide any means of contacting them. At least not
until you provide something like a DNA sample. Then what will you receive?
SPAM.

When they allowed commercial interests onto the web in the early to mid
1990's, it's been downhill from there.

[Rich]

Post by Cri-Cri

Post by Rich
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.

I suppose one could pester them with questions on a daily basis,
until they learned that it would be easier to put the date on the
page already from day one. :)

Provided one has a /way/ to pester them....

Post by Cri-Cri
Then again, I also see a trend that companies that are represented on
the web, these days seldom provide any means of contacting them.

Yes, this is indeed the problem. Most want to "broadcast", but never
"receive", any information.

Post by Cri-Cri
At least not until you provide something like a DNA sample. Then
what will you receive? SPAM.

Yup.

Post by Cri-Cri
When they allowed commercial interests onto the web in the early to
mid 1990's, it's been downhill from there.

One could argue that "the web" might not be as big as it is at present
without those ommercial interests. But there has been a lot lost in
pursuit of that growth as well.

[Cri-Cri]

Post by Rich

Post by Cri-Cri
the web, these days seldom provide any means of contacting them.

Yes, this is indeed the problem. Most want to "broadcast", but never
"receive", any information.

With email there used to be this required recipient mailbox "postmaster"
on email servers, through which the email admin received, e.g., complaints
about misuse of resources, or other things deemed "illegal", from an email
and a general online conduct perspective.

Although it may still be required, I don't think this mailbox is monitored
by many admins these days. Or you need to be in on some secret usage of
vocabulary to circumvent heavy filtering.

I see the same trend in the whois protocol. Information is stripped for
"integrity" and "protection" reasons, but it can't be "personal integrity"
or "protection of the individual", since we are dealing with the majority
being companies that own the domains which are registered with the whois
protocol.

Same trend on Usenet. One can no longer see the path to servers (at least
not on my server). Now it just says "Path: not-for-mail." When I asked
about it, they, of course, said "for security reasons." They are now
protecting spammers and header fakers and they are in breach of the RFC
"rule book." I pointed that out to them. Result? Silence.

So, who's to blame? SPAM and script kiddies and probably what you said:
they only want to broadcast, not receive.

The whole damn thing is turning into old time radio!

Post by Rich
One could argue that "the web" might not be as big as it is at present
without those ommercial interests. But there has been a lot lost in
pursuit of that growth as well.

"Money makes the world go around."

[Rich]

Post by Cri-Cri

Post by Rich

Post by Cri-Cri
the web, these days seldom provide any means of contacting them.

Yes, this is indeed the problem. Most want to "broadcast", but never
"receive", any information.

With email there used to be this required recipient mailbox "postmaster"
on email servers, through which the email admin received, e.g., complaints
about misuse of resources, or other things deemed "illegal", from an email
and a general online conduct perspective.
Although it may still be required, I don't think this mailbox is monitored
by many admins these days. Or you need to be in on some secret usage of
vocabulary to circumvent heavy filtering.

Yeah, I feel like email to ***@bigsite.com just about anywhere
will either bounce (at least you know it went nowhere) or go into an
email black hole never to be seen nor heard from again.

Post by Cri-Cri
Same trend on Usenet. One can no longer see the path to servers (at least
not on my server). Now it just says "Path: not-for-mail."

Works fine here:

Path: eternal-september.org!news.eternal-september.org!feeder3.eternal-september.org!panix!usenet.blueworldhosting.com!diab
lo1.usenet.blueworldhosting.com!peer01.iad!feed-me.highwinds-media.com!peer03.ams4!peer.am4.highwinds-media.com!news.highwi
nds-media.com!fx05.ams4.POSTED!not-for-mail

That's your path header from the article this is a reply to.

So either Pan is not showing you the full header, or something real
funky is happening with easynews's nntp feed.

Post by Cri-Cri
When I asked about it, they, of course, said "for security reasons."

That's often the "we don't know, we don't care, we just want you to go
away" answer -- and for many it does cause them to "just go away".

[Paul Leyland]

Post by Rich

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

I prefer not to put the last-modified date on the visible page. Anyone
who really wants to know can look at the HTML. For instance, from
www.astropalma.com

<head>
<title>Tacande Observatory, La Palma</title>
<link type="text/css" rel="stylesheet" href="de.css">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
<meta name="author" content="Paul Leyland"/>
<meta name="generator" content="GNU Emacs 26.3"/>
<meta name="revised" content="20210819T1136"/>
<meta name="X-Clacks-Overhead" content="GNU Terry Pratchet"/>
</head>

Perhaps others do much the same.

[Stefan Claas]

Post by Rich

Post by Stefan Claas
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;"

Post by Rich

Post by Stefan Claas
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.

[Rich]

Post by Stefan Claas

Post by Rich

Post by Stefan Claas
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.

Post by Stefan Claas

Post by Rich

Post by Stefan Claas
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'....

[Stefan Claas]

Post by Rich

Post by Stefan Claas
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.

[Cri-Cri]

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.

[Stefan Claas]

Post by Cri-Cri

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.

[Rich]

Post by Stefan Claas

Post by Rich

Post by Stefan Claas
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]

Post by Stefan Claas
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/

[Rich]

Post by Cri-Cri

Post by Stefan Claas
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.

[Chris M. Thomasson]

Post by Stefan Claas
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:

Loading Image...

The plaintext is:

A key:

f65952b125ba6860e21aef9c55e69e0612b153e5fd2599ac00b67945f9bec7563d5edf8bf9fa0db27aeb78b0c8f40f0a6a69b2cd720d59ecc73a01c1ccad0933cfe9e014dda35db6eaba760c9dbdff0f4ad24c5b702baab8e225189179b8bd

[Stefan Claas]

Post by Chris M. Thomasson

Post by Stefan Claas
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.

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
https://i.ibb.co/BybrYDw/image.png
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?

[Rich]

Post by Chris M. Thomasson
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
https://i.ibb.co/BybrYDw/image.png
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?

[Chris M. Thomasson]

Post by Rich

Post by Chris M. Thomasson
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
https://i.ibb.co/BybrYDw/image.png
f65952b125ba6860e21aef9c55e69e0612b153e5fd2599ac00b67945f9bec7563d5edf8bf9fa0db27aeb78b0c8f40f0a6a69b2cd720d59ecc73a01c1ccad0933cfe9e014dda35db6eaba760c9dbdff0f4ad24c5b702baab8e225189179b8bd

Your site says it does key generation from 64 random bytes. How do
you remember the key when traveling, with no device?

Wrt my HMAC cipher as is, you only need to remember the password for a
given ciphertext in order to decrypt it.

However, afaict, this is not what you are looking for wrt key generation
since my code generates a new ciphertext per encryption even if the
plaintext and/or password is the same.

Post by Rich

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

Well, I guess you can examine the source code of my site. It's client
only, no server side logic.

Post by Rich
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?

[Stefan Claas]

Post by Rich

Post by Chris M. Thomasson
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
https://i.ibb.co/BybrYDw/image.png
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?

Prior upload and departure I can write down on a piece of paper the shasum
and once arrived at my destination I can compare the shasum from the download
with the shasum on paper. Only problem would be IMHO, if the shasum would
no longer match and I have no plan B.

[Rich]

Post by Stefan Claas

Post by Rich

Post by Chris M. Thomasson
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
https://i.ibb.co/BybrYDw/image.png
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?

Prior upload and departure I can write down on a piece of paper the
shasum and once arrived at my destination I can compare the shasum
from the download with the shasum on paper.

That would work, presuming the border crossing guards do not question
your shasum paper....

Post by Stefan Claas
Only problem would be IMHO, if the shasum would no longer match and I
have no plan B.

True, but at least you can recognize you've been targeted, and know not
to trust the binary currently on github.

[Stefan Claas]

Post by Rich

Post by Stefan Claas
Prior upload and departure I can write down on a piece of paper the
shasum and once arrived at my destination I can compare the shasum
from the download with the shasum on paper.

That would work, presuming the border crossing guards do not question
your shasum paper....

Post by Stefan Claas
Only problem would be IMHO, if the shasum would no longer match and I
have no plan B.

True, but at least you can recognize you've been targeted, and know not
to trust the binary currently on github.

And to notify, for example, people on Usenet I can then download
GnuPG 1.4 Windows from my GitHub repository and use that to post,
without nntp credentials, to Usenet, via an additional Gmail account.

In that case it doesn't matter if this repository would be compromised
as well, or a key logger is installed in an Internet Café.

[Chris M. Thomasson]

Post by Stefan Claas

Post by Chris M. Thomasson

Post by Stefan Claas
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.

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
https://i.ibb.co/BybrYDw/image.png
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?

Well, yeah. Shit. Sorry what I wrote does not solve your problem. The
problem is on my end for your specific goal. The issue is is that each
time you click encrypt on my site, it will generate a new ciphertext
even if the plaintext is the same. I take it that this is not what you
are looking for! Am I right that you want the same ciphertext generated
for each encryption? A password creates a unique key, in the form of the
generated ciphertext?

Fwiw, my online program needs to use an actual TRNG to follow my rules here:

http://funwithfractals.atspace.cc/ct_cipher/

Using a TRNG for the following function in my code is ideal in:

https://fractallife247.com/test/hmac_cipher/ver_0_0_0_1/ct_main.js
___________
function ct_rand_bytes(n) {
var output = new Array();

for (var i = 0; i < n; ++i) {
var byte = Math.floor(Math.random() * 255);
output.push(byte);
}

return output;
}
___________

That is NOT using a TRNG, ARGH!!!

[Peter Fairbrother]

Post by Stefan Claas
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

[Oscar]

Post by Stefan Claas
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.

Someone already mentioned using python hash functions, but perhaps;
sha1sum <some file on the device>

If you don't want to bring <some file> with you, you can download it later.

Or just make up some lengthy password and translate it manually to "hex
digits" using "man ascii".

Or just try to remember some fun hexdigits literally like deadbeef,
b000b5, caffee etc ..

Cheers,
Oscar