Path: ...!feed.opticnetworks.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Rich <rich@example.invalid>
Newsgroups: sci.crypt
Subject: Re: Memorizing a 128 bit / 256 bit hex key
Date: Thu, 20 Jun 2024 03:14:45 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 55
Message-ID: <v506r5$2cucm$1@dont-email.me>
References: <v4s3ld$bu48$1@i2pn2.org> <v4vb9v$2478p$1@dont-email.me> <v4vbth$fvtf$1@i2pn2.org> <v4vcm5$24hrj$2@dont-email.me> <v4vh27$g5tv$3@i2pn2.org>
Injection-Date: Thu, 20 Jun 2024 05:14:46 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="5bdc0c3dfc9fa55cdda166dac217f191";
	logging-data="2521494"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18ZqqKU/jmLe/hbP2EO7dHL"
User-Agent: tin/2.6.1-20211226 ("Convalmore") (Linux/5.15.139 (x86_64))
Cancel-Lock: sha1:5BzwDN6dIvW/BMDs73KuqTg0sYw=
Bytes: 3897

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.