Re: Big curiosity
Hello, a bit of elaborating on this one. Am Sun, 13 Jun 2021 18:58:54 +0200 schrieb Johan Wevers : > On 13-06-2021 16:06, knighttemplar5--- via Gnupg-users wrote: > >> I have been contemplating subscribing to an email forwarding service >> that will encrypt all the forwarded mails to me with my public key. >> Lets imagine the country where the forwarding takes place can see all my >> emails in plain text and at the same time the same emails PGP encrypted, >> can enough of this data pose a threat to my private key? > > What you describe is in cryptography known as a known-plaintext attack. > Correct. > It can happen in a less obvious way. For example I remember the old Word > Perfect 5 for DOS that had the option to encrypt its files. It did that > by XORing the entire file with your password. However, because the first > few bytes of a WP file were always the same it was trivial to deduct the > password from a file that was encrypted with this method. > Yet let us keep in mind that gpg (or any practical assymetric encryption kit out there) consists of two elements: an asymmetric encryption and a symmetric encryption. The XOR is the symmetric part, and there is a lot of discussion on the resilience of a symmetric cipher to chosen plaintext attacks when it is being reviewed. XOR is a good example here because it is so poor in this respect. Modern variants are thought to be resilient against this type of attacs - typical reviews might tell you that in order to break a 128 bit key one would need 2**90 or so texts and their encrypted equivalent. The actual number for gpg security is practically not relevant, since for gpg you'll get a different symmetric key each time you encrypt another file. This is because gpg actually only encrypts this symmetric key with the assymetric code, like RSA - typically not more than 256 bit of arbitrary nature. For the assymetric code the world is different - anybody who has access to the public key can generate as many plaintext/ciphertext pairs as he wants. Yet I am not aware of any (relevant) choosen plaintext attacs against RSA & friends - this would immediately render it useless, for any application. > > So, in short, the answer to your question is "no, it is not a threat". > Absolutely right. You should be more concerned to understand what this type of incoming mail encryption is good for - and what it can't prevent. It is not as useful as you may think; the mail provider could still read your plaintext mail, even though he may promise you to encrypt things directly after receiving. The link from your email provider to you is, these days, already encrypted, so no benefit there neither. The one benefit is that if someone hacks your mail provider he can't do anything with your mails he may find there, since they are all encrypted. So yes it is useful, but only in a specific way. Hope this helps, regards Andreas -- Lister: Everything?s really nice there. They even shampoo the rats. Groom their tails and everything! ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: decryption failed: No pinentry
Hello, Am Mon, 31 May 2021 07:59:35 +0200 schrieb Christopher Richardson via Gnupg-users: > This is probably something very trivial, but Im building gpg for the > first time since, apparently, 2013, according to my old binary. The build > seems fine, but ... > a bit of a longshot, but if your pinintry is also as of 2013 there might (might!) be incompatabilities with a modern gpg? The obvious thing would be to also update pinentry, which is painless. You can specify a pinentry program during the configure step when building gpg. I haven't done this, and it still finds pinentry and works fine. I could not spot that configure would do any other checks on pinentry on the system (checking usability etc.). I don't have any pinentry defined in any of my settings in .gnupg/ neither. Regards Andreas ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: CCID no longer working
Hello Werner, thanks for the feedback. Am Wed, 26 May 2021 16:49:07 +0200 schrieb Werner Koch via Gnupg-users: > pcscd grabbed the device and thus scdameon can't open it. We don't have > a fallback to PC/SC anymore thus you see this error instead of scdaemon > silently switching from internal CCID to PC/SC. > > I can confirm this, heuristically: I reenabled ccid for scdaemon, terminated pcscd and scdaemon and tryed gpg --card-status again, which duly prompted the expected information. Regards Andreas ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
CCID no longer working
Hello, for a few weeks now gpg has been unable to contact my smartcard. I have recently updated to gpg 2.3.1, so it *might* have to do with that, but I can't positively confirm. Things had been working flawlessly until then. Running scdaemon with debug gave a telltale hint: 2021-05-25 21:33:11 scdaemon[13946] DBG: chan_7 -> D /home/andreas/.gnupg/S.scdaemon 2021-05-25 21:33:11 scdaemon[13946] DBG: chan_7 -> OK 2021-05-25 21:33:11 scdaemon[13946] DBG: chan_7 <- OPTION event-signal=12 2021-05-25 21:33:11 scdaemon[13946] DBG: chan_7 -> OK 2021-05-25 21:33:11 scdaemon[13946] DBG: chan_7 <- GETINFO version 2021-05-25 21:33:11 scdaemon[13946] DBG: chan_7 -> D 2.3.1 2021-05-25 21:33:11 scdaemon[13946] DBG: chan_7 -> OK 2021-05-25 21:33:11 scdaemon[13946] DBG: chan_7 <- SERIALNO 2021-05-25 21:33:11 scdaemon[13946] ccid open error: skip 2021-05-25 21:33:11 scdaemon[13946] check permission of USB device at Bus 005 Device 004 2021-05-25 21:33:11 scdaemon[13946] DBG: chan_7 -> ERR 100696144 Kein passendes Gerät gefunden 2021-05-25 21:33:11 scdaemon[13946] DBG: chan_7 <- RESTART 2021-05-25 21:33:11 scdaemon[13946] DBG: chan_7 -> OK I then put "disable-ccid" into scmdaemon.conf, and things started working again - I have pcscd running anyway. The system is not running udev, the device nodes are static. I had no trouble earlier, so I would assume permissions are not an issue - one would think 666 to be sufficient: crw-rw-rw- 1 root root 189, 515 25. Mai 21:34 /dev/bus/usb/005/004 gpg 2.3.1 has been out for a month now, and I assume that if there were an issue with CCID there would be some related noise on the mailing list, but there isn't. Maybe it's worth a casual look from our esteemed developers. Regards Andreas Mattheiss ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Which keyserver
Hello, >Is it possible to define multiple sources of keys with WKD, for example >with a dns TXT record? Well, yes, actually. This can be done with both X509 certificates (where it is called SMIMEA) and gpg keys. Obtaining a key basically involves quering the appropriate TYPE in the DNS record (53 for SMIMEA, 61 for openpgp). An additional step is to check the authenticity of this record. All this is completely seperate from WKD though. That's the theory. In practise, alas, bugger all's using it. It's a shame, since this would really be a big step forward. The catch here is that it needs to be supported by the mail server where the addressee has his account. Needless to mention it is hardly deployed; in Germany mail.de has it, as do a number of paid email services. Plus, of course: before this goes big, the big email clients would have to support it. Of course you can hack something together using only command line tools (I've done that), but that's not the cup of tea for 99.9% of normal email users. Vincent Breitmoser described this in this thread eloquently as being used by effectively nobody but a rounding error. Sigh. Andreas ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Vanity Key@@sig
Well, uhm, if it's really important to you: The concept of hashes/fingerprints/etc. is that it is (next to) impossible to find an entity-to-be-hashed (here a key) if you specify the hash. In fact a hash function that allows you to do this would be cryptographically frowned upon. However, there is nothing that stops you from generation a gazillon of keys, until you - by chance - get one with a hash you like. This brute force approach is what is behind bitcoin mining or hashcashing email messages - the latter, sadly, an idea ignored by the general public. Regards Andreas -- LISTER: Me. No another one for you. Rear Admiral Lieutenant General Rimmer. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Information on a gpg encrypted file
Hello, I wonder if there is a utility that, when fed a gpg-encrypted-message, will tell me which key is needed, which compression/cipher/hash was used. Regards Andreas -- RIMMER: Lister, we'd be fools not to listen to him. When is he ever wrong? Alright, he may have a head shaped like an inexplicably popular fishing float but he does operate from a position of total logic and we'd be fools to ignore his sage council. KRYTEN:At least let me and Mister Rimmer go in your place. We are after all merely electronic life forms and therefore expendable. RIMMER: And what the smeg would you know, bog-bot from hell? ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Information on a gpg encrypted file
Thanks for the reply. Am Sat, 20 Oct 2012 00:18:40 +0200 schrieb Werner Koch: For an encrypted message the other information are only available after decryption. I see. Looks like this basic handling info is also encrypted with the unsymmetric key. In fact it needs gpg -vvv to elicit this information: ... gpg: TWOFISH encrypted data :compressed packet: algo=3 ... Reason for asking was because I played around a bit with the compression/cipher preferences in my public key and wanted to see if it actually uses say TWOFISH if I put it to the top of the queue of acceptable ciphers. It does. Thanks, regards Andreas -- LISTER: But we don't loot space corp derelicts. We just hack our way in and swipe what we *need*. RIMMER: If this goes to trial, I demand seperate lawyers. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
