All my Passwords are lost

Marek Stepanek mstep at podiuminternational.org
Sun Apr 25 17:31:53 CEST 2021


Hello all,

Thank you for your answers. Hope I respond to your questions: 

I encrypt in my Shell as follows - I am doing it just now with a Backup File on my desktop:

$ gpg bu_pw_new.txt.gpg
gpg: WARNING: no command supplied.  Trying to guess what you mean ...
gpg: encrypted with 2048-bit ELG key, ID F5FF48588C144291, created 2010-08-05
      "Marek Stepanek <marek at munich-taxis.de>”

If I change something with VIM I make: 

$ rm bu_pw_new.txt.gpg
$ gpg -e bu_pw_new.txt
You did not specify a user ID. (you may use "-r")

Current recipients:

Enter the user ID.  End with an empty line: marek
gpg: F5FF48588C144291: There is no assurance this key belongs to the named user

sub  elg2048/F5FF48588C144291 2010-08-05 Marek Stepanek <marek at munich-taxis.de>
 Primary key fingerprint: B607 17A3 A754 8564 B209  6A9B D442 9D47 8F5D ABEF
      Subkey fingerprint: 4CE5 48A1 9A35 DCD7 D18D  183B F5FF 4858 8C14 4291

It is NOT certain that the key belongs to the person named
in the user ID.  If you *really* know what you are doing,
you may answer the next question with yes.

Use this key anyway? (y/N) y

Current recipients:
elg2048/F5FF48588C144291 2010-08-05 "Marek Stepanek <marek at munich-taxis.de>"

Enter the user ID.  End with an empty line:

And here it is encrypted again. Then I remove the raw text file:

$ rm bu_pw_new.txt

I am unsure how GnuPG could pick up the wrong key, which does not exist in my key deposit. My guess is, that it is encrypted anyway with my private key, but the headers are mangled up??? For that reason my question was: may I replace some headers from my backup file ( two month old! ) into the spoiled one? But until where? For that reason I was posting here, to ask some of the developers how to achieve it right. There are plenty of those <85> … <8c> … <91> - cutting the binary file in some pieces (?) 

Thank you Vincent for your detailed answer, which is way over my head. I really should look into the internals of file encryption one day … 

Is pause at pause.perl.org <mailto:pause at pause.perl.org> listening? Is your PGP key still in use? 

Best greetings to all


marek



> On 25. Apr 2021, at 10:41, Vincent Pelletier <plr.vincent at gmail.com> wrote:
> 
> On Sat, 24 Apr 2021 15:19:07 -0700, "C.J. Collier" <cjac at colliertech.org> wrote:
>> you could maybe ask a pause admin to decrypt and
>> re-encrypt to a key that you own, sending you back the encrypted file.
> 
> Two ideas from a gpg-internal *UN*aware point of view:
> - I assume gpg file encryption works by generating a random symmetric
>  cipher key, encrypting the file with this symmetric cipher, and
>  only encrypting the symmetric cipher's key with the asymmetric cipher
>  public key.
>  If so, then the encrypted symmetric key could in theory (...again, I
>  do not know enough of gnupg internals) be extracted and be the only
>  thing sent for decryption and sent back deciphered.
>  Of course, it means that if the file was leaked encrypted, then this
>  deciphered key intercepted, then the file is completely leaked.
> - Is the asymmetric algorithm transitive ? If it is, then again
>  starting from an extracted encrypted key, it could be encrypted again
>  with the good public key, then sent for decryption. The key received
>  back would still be encrypted by the good public key. It can then
>  finally be deciphered, allowing the symmetric cipher to decipher the data.
>  This would solve the plain-text vulnerability of the previous point.
> 
> I believe (again, not an expert) decryption and signature use different
> parameters in gpg, so from the pause admin point of view they should
> not be worried about inadvertently signing a hash, but actually
> deciphering a symmetric key (which can otherwise be a concern).
> -- 
> Vincent Pelletier
> GPG fingerprint 983A E8B7 3B91 1598 7A92 3845 CAC9 3691 4257 B0C1
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20210425/8f5175ab/attachment.html>


More information about the Gnupg-users mailing list