News from da outaworlds |
mail files register groups login |
Message-ID: |
Pages:12 |
On 18/06/2024 15:05, 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.
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
On 18/06/2024 15:37, Stefan Claas wrote:
> 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.
Hmm, from where? Threat analysis?
> 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
On 6/19/2024 12:35 PM, Stefan Claas wrote:
> 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?
>
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!!!
On 6/19/2024 12:48 PM, Rich wrote:
> 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?
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.
>
>> 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.
>
> 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?
>
Op 18-6-2024 om 15:55 schreef 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
Peter Fairbrother wrote:
> On 18/06/2024 15:37, Stefan Claas wrote:
> > 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.
>
> 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.
> > 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 wrote:
> On 18/06/2024 15:05, 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.
>
> 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.
--
Regards
Stefan
Rich wrote:
> 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?
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.
--
Regards
Stefan
Stefan Claas <pollux@tilde.club> wrote:
> Rich wrote:
>
>> 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?
>
> 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....
> 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.
On Wed, 19 Jun 2024 19:43:09 -0000 (UTC), Rich wrote:
> 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.
--
Cri-Cri
Cri-Cri <cri@cri.cri.invalid> wrote:
> On Wed, 19 Jun 2024 19:43:09 -0000 (UTC), Rich wrote:
>
>> 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....
> 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.
> At least not until you provide something like a DNA sample. Then
> what will you receive? SPAM.
Yup.
> 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.
Rich wrote:
> Stefan Claas <pollux@tilde.club> wrote:
> > 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....
>
> > 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é.
--
Regards
Stefan
On Thu, 20 Jun 2024 15:54:30 -0000 (UTC), Rich wrote:
>> 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!
> 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."
--
Cri-Cri
Cri-Cri <cri@cri.cri.invalid> wrote:
> On Thu, 20 Jun 2024 15:54:30 -0000 (UTC), Rich wrote:
>
>>> 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 postmaster@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.
> 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.
> 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".
On 19/06/2024 03:53, Rich wrote:
> 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).
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.
Pages:12 |