Kleopatra does not show diasbled keys though defined in libkleopatrarc
Hello! I want to visually distinguish disabled OpenPGP-keys in Kleopatras interface. Therefor I edited inlibkleopatrarc and added a category "Disabled keys" to it: [Key Filter #10] Name=Disabled keys font-italic=true foreground-color=186,189,182 is-disabled=true As a result I would expect to appear disabled keys to appear in grey and italic. Though the new category is listed in Kleopatras settings after the edit and though the relevant keys are recognized as disabled in the mouse-over-box the visual settings are not applied. This happens in the current Kleoptra included in GPG4Win 3.1.16, Debian 11.1 (Bullseye) and Ubuntu Budgie 21.4.3. I am not sure at all, but I think this was working some time in the past Thanks for Help! Karel ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: GPG4Win 3.1.16: mkportable.exe missing?
Hello! I did a complete uninstall of GPG4Win with exception of the personal data in my homedir, restarted my machine and installed GPG4Win with all options selected (usually I install it without GPG-OL). Once again mkportable.exe and paperkey.exe were missing though the rest of my GPG4win-Installation was working as expected. I was able to locate the missing files in the 3.1.16 installer and extracted them manually using 7-Zip. Thus I was able to create a portable installation. I found no reason why mkportable and paperkey were not installed, there were no entries in my virus scanners log (Windows Defender) or any other signs for abnormal behaviour of my system. Greetings Karel 12. Juli 2021, 14:05 von bernh...@intevation.de: > Hello Karel, > > Am Samstag, 3. Juli 2021, 22:29:15 CEST schrieb karel-v_g--- via Gnupg-users: > >> After Updating from GPG4Win 3.1.15 to .16 I noticed that the newest build >> does not install mkportable.exe?! Is it missing by intend or by accident? >> > > as far as I know mkportable works in principle on Gpg4win 3.1.16, > see success reports on https://dev.gnupg.org/T5287 > > So the question is why does it not install for you. > Can you try a reinstall and select all components? > >> PS: I hope it is okay to ask this GPG4Win-related question here on the >> GnuPG-list!? >> > > To me it is okay, though gpg4win-users...@wald.intevation.org is even more > appropriate. If possible, followup there. (You need to subscribe to the list.) > > Best Regards, > Bernhard > -- > www.intevation.de/~bernhard +49 541 33 508 3-3 > Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998 > Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner > ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
GPG4Win 3.1.16: mkportable.exe missing?
Hello! After Updating from GPG4Win 3.1.15 to .16 I noticed that the newest build does not install mkportable.exe?! Is it missing by intend or by accident? How can I make the latest build portable? Thanks for help! Karel PS: I hope it is okay to ask this GPG4Win-related question here on the GnuPG-list!? ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
GnuPG 2.3.0: AEAD - no GCM-Mode?
Hello! Another question: why donˋt you use GCM as a possible mode for AEAD? It seems to be the most common nowadays and was also implemented in S/MIME v4 to overcome efail.Cheers Karel ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
GnuPG 2.3.0: new ECC curves
Hello! The list of additions and changes to GnuPG 2.3 is quite impressive. Thanks for all the work on GnuPG. Just out of curiosity one question: why did you "only" add curve x448 from the SafeCurves project and not also E-521? For NIST and Brainpool the available curves >500bits are also already supported. Cheers Karel ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
GPA: How to get long Key-ID displayed
Hello! For me GPA always display only the old short Key-ID. How / where can I change that? I have not found any option in the GUI or for gpa.conf. For GnuPG itself I have already set "keyid-format 0xlong" in gpg.conf, but that does not affect GPA. Thanks for help! Karel ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
GPA: How to get long Key-ID displayed
Hello! For me GPA always display only the old short Key-ID. How / where can I change that? I have not found any option in the GUI or for gpa.conf. For GnuPG itself I have already set "keyid-format 0xlong" in gpg.conf, but that does not affect GPA. Thanks for help! Karel ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Kleopatra and GPA: Differentiate diabled and revoked keys optically
Hello! Over the years I have collected quiet a few personal private and foreign public keys that were either revoked or that I have simply disabled. How can I configure Kleopatra and GPA to either optically differentiate, hide or these keys? GPA displays all keys in the same manner and I have found no way to change this. For Kleopatra I can change the visual style of these key-types in libkleopatrarc, but I wonder whether there is an option to sort these keys at the beginning or end of the list or hide them. Thanks for help! Karel ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Precompiled Windows-Binaries with Large-Secmem-Support
> > "Because I think it would be cool" is a good answer if you're the one > writing the patch and volunteering to do long-term support of it. All > other people need to be able to answer it. > Hello! I suspect the tone of your reply and the fact that you put me near script kiddies is due to the previous discussions about key length?! So let me set the record straight on a few things: I did not talk about 16384bit keys, nor did I suggest or demand a patch for GnuPG. I merely asked why the official Windows binaries (at least those inGPG4Win) are not compiled with the already existing option "enable-large-secmem", which would allow keys up to 8192bit in batch mode operation, and suggested to do so in future versions. Much has already been argued about the sense or nonsense, we don't need to repeat that here. But the option is already implemented and used in other ready-made packages, e.g. in Debian Buster. So to the best of my knowledge beyond a setting switch when compiling new versions, there would be no long-term support effort in the code. So why not also under Windows? Karel ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Plan B - Who carries the torch?
>Yeah. Less time worrying about how to make OpenPGP continue for>another >twenty years, more time spent about how to make a next->generation >cryptographic tool that will occupy the same space OpenPGP>did but will do it >better and with more modern techniques. I totally agree with you on that. Though I have no idea how to do it, I think in the midterm we need something totally new with modern crypto-technology, easy to use and lean. Like WireGuard for VPN or the modern messengers. Unfortunately OpenPGP and S/MIME have not managed to conquer a broad public and sometimes even not to keep up with modern standards in the last twenty years. Sorry for criticising without suggesting a solution.Karel ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Precompiled Windows-Binaries with Large-Secmem-Support
Hello! I know there are and have been fierce discussions about the useful length of RSA-Keys. I don't want to dive deeper into that, and I hope this special question has not been discussed recently: The generation of large RSA-Keys is extremely well hidden for normal users, it requires batch-mode, enable-large-rsa and a special file with instructions. Thus the danger for inexperienced users to mess up their keys is rather low. Nevertheless the officially available precompiled Windows-Binaries come without support for these large keys (at least those included into GPG4Win). May I suggest to compile future builds for Windows with enable-large-secmem?! Thanks for discussing and considering. Karel ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Certified OpenPGP-encryption after release of Thunderbird 78
Hello! No, I don't work for an Aufsichtsbehörde and (fortunately) I don't have to deal with them directly most time. But the Aufsichtsbehörde defines how my work has to be done and they have the right to inspect it. And one of the things they require is use recommended (e.g. BSI) software for mailencryption. Of course there is no way knowing for them whether I comply or not without intercepting my mail or visiting my office. But as always it might cause problems when not complying. So I think I will continue use Thunderbird as MTA and use GPG4Win with copy and paste for the encryption part. But it's a pity that Thunderbird developed its own solution because of licensing issues while we have a proven working solution with GnuPG... But why should I take the discussion personal?? :-) Karel 28. Mai 2020, 23:21 von s...@300baud.de: > karel-v_g--- via Gnupg-users wrote: > > >> Hello! >> The German translation should be "Aufsichtsbehörde" (or even better >> "Rechtsfähige Anstalt des öffentlichen Rechts"). In fact I don't know >> the exact translation and didn't find any appropriate in >> Google-Translate or deepl. So "supervising authorities" was my best >> guess without being a native speaker... Does this change the meaning >> or anything else? Karel >> > > Hi, > > while it is not my business, I do not understand why you have to take > care about the Thunderbird issue, as a users and not the > Aufsichtsbehörde ... If for example you have a job at the > Aufsichtsbehörde then ok, like I said, I would contact gnupg.com and > ask them if GnuPG Desktop (A Windows app) fits for your working > environment and in case not what they would suggest, because the > Aufsichtsbehörde should have IMHO funds to issue a professional > licensed working solution for their employees. > > In case you only have to deal as a gpg4win user with the > Aufsichtsbehörde via email, then I don't understand how would they > detect if you would not comply by using later the new Thunderbird, > without BSI approval. > > P.S. please don't take it personal! > > Regards > Stefan > ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Certified OpenPGP-encryption after release of Thunderbird 78
Hello! The German translation should be "Aufsichtsbehörde" (or even better "Rechtsfähige Anstalt des öffentlichen Rechts"). In fact I don't know the exact translation and didn't find any appropriate in Google-Translate or deepl. So "supervising authorities" was my best guess without being a native speaker... Does this change the meaning or anything else? Karel 27. Mai 2020, 23:41 von s...@300baud.de: > karel-v_g--- via Gnupg-users wrote: > > >> Hello! >> > > [...] > >> Aside from advising to use BSI-certified products the authorities are >> not of any help unfortunately... >> > > In your previous post you spoke about *supervising* authorities. > > https://en.wikipedia.org/wiki/Supervisor > > > Regards > Stefan > ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Certified OpenPGP-encryption after release of Thunderbird 78
Hello! >I just checked the BSI's list of certified products. Gpg4Win andGpg4KDE are >currently listed until >2022-06-30, and you can continueusing them. >Thunderbird and Enigmail are not included in that list,so >you are apparently >using your own software mix anyway. Indeed, the only certified component of my mix is GPG4Win, while Enigmail and Thunderbird aren't. But I had checked that before I implemented that combination: the authorities said that only the part of the software that handles the encryption process needs to be certified while the used mail-client and plugins only need to meet general security requirements (TLS-Connections, latest patch-level, ...). Aside from advising to use BSI-certified products the authorities are not of any help unfortunately... So, to be a bit more precise: is there any mailclient working directly with GPG4win or other certified OpenPGP-solution aside from Outlook or copy and paste with Thunderbird 78ff? Thanks! Karel ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Certified OpenPGP-encryption after release of Thunderbird 78
Hello! I am required to use certified encryption for mails by my supervising authorities and good practise. Because of this I have been using a combination of Thunderbird, Enigmail and Gpg4Win, as the latter one is certified by German BSI. With the approaching release of Thunderbird 78 Gpg4Win and Enigmail won't be available any longer and the new OpenPGP-implementation of Thunderbird won't be certified to the best of my knowledge. I am aware this might be slightly OT for this list, but are there any suggestions what can be done to keep up a certified encrypted mail communication? I am afraid Outlook which should work easily with Gpg4Win is not an option. Thanks for suggestions and help! Karel ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
BSI withdraws approval of GnuPG (revisited after 3 month)
Hello! In May 2019 the German Federal Office for Information security (Bundesamt für Sicherheit in der Informationstechnik, BSI [1]) approved GnuPG for securing data of the lowest security classification (VS Nur für den Dienstgebrauch, comparable to NATO Restricted). [2] This approval was withdrawn for an unknown reason somewhen before July 21st 2019. Heise-Online reported this on August 6th 2019. According to them the BSI said it hopes to reissue the approval soon, but further inquiries remained unanswered. [3] In a message to this list on August 8th Werner Koch said he is permanent contact with BSI and the reason for the withdrawal is in the OpenPGP part of GnuPG. Once again no further details were provided. [4] Since then there is silence on the topic for the past three month. As 90 days is the period we all know from Googles notorious Project Zero I would like to come back on the problem now. Are there any news? Should we consider our data protected by GnuPG insecure as german authorities obviously do? Can or must we take any steps to eliminate or at least mitigate the problem in the current modern (2.2.17) and classic 1.4.23) versions of GnuPG (e.g. avoid compatibility options like —openpgp)? Is it a problem only with GnuPG or with OpenPGP in general? Are other implementations affected as well? When can we expect further information? Thanks Karel [1] www.bsi.de [2] heise.de/~4416766 [3] heise.de/~4489547 (06.08) [4] lists.gnupg.org/pipermail/gnupg-users/2019-August/062520.html (09.08.) ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Some thoughts on the future of OpenPGP and GnuPG
Hello! Just right now I have read about a security vulnerability in the PGP keyservers, that can likely not be fixed according to Heise Online. That makes me writing about something I have been thinking of for quiet some time now: I am working in an environment that deals with highly sensitive personal data and my first PGP-key dates back to as far as the mid 1990s. Meanwhile I have changed it a few times, going from PGP 2.3 to the DH/DSS-Keys propagated by PGP 5 and then back to RSA-Keys with GnuPG. When looking at my In- and Outbox over the whole time I can safely say that I received and send only about 25 (!) mails in all the years and that many of my contacts simply have no PGP or don't use it any longer. It is easier and more reliable to send sensitive data by fax or mail for them. Many attempts to make mail encryption easier have failed and the standards we have for it are aging. S/MIME was never repaired after the so called efail-attack and OpenPGP relies on a SHA1-based modification detection code to protect from it as far as I know. Many other aspects are also far from moderns standards. Beyond this the complicated (and now dysfunctional as stated above) keydistribution caused many people to either send mails unencrypted, use regular mail or fax or use encrypting messengers nowadays. The renewal of the OpenPGP-standard has stopped or stalled last year and the additions to GnuPG were also rather small in the past years (aside from ECC). So my question as a user with a need for strong mail encryption is, whether it is not a time to start over with an all new encryption standard replacing OpenPGP and S/MIME completely. Something like the much praised Wireguard is doing right now in the VPN-world. Implementing just one (or two if needed) standardized modern method for each of the following basic components: s2k-function, hash algorithm, authenticating symmetric crypto-algorithm, one ECC-based and one conventional asymmetric crypto-algorithm. And somethin to ease the key distribution. OPENPGPKEY and WKD might be suitable for that. Thats it. No backwards compatibility. All new lean and easy. In my experience there are so few people actually using OpenPGP and these are crypto experienced so they should eysily adopt the modern proposal. If really needed the old standards could be supported for some time in a seperate "classic" component, but without the ability to create new keys. To propagate the distribution of this hypothetical new format it might be useful to get some of the major mailproviders, business software companies and mail software vendors might be useful, another problem of OpenPGP was and is that aditional software components are needed. Once again: I know that won't be easy or perhaps it can't be done at all. I really appreciate the work and commitment of Werner and all the others here and I am donatig each year to support them. But their work is simply not working in the real world. Sorry to say so, but that's my eperience and view as a user -or let's better say wannabe user as there is no one to write encrypted mails to... ;) Thanks for reading and discussing! Karel ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
OpenPGP-Card v3.3 - ECC Curve25519 supported?
Hello! I have seen that the latest revision of OpenPGP-cards (3.3) supports ECC-keys and is available for sale. Does this also include curve25519 or "only" Brainpool and NIST? Thanks for enlightment! Karel ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Test symmetrically encrypted files for errors - make sure they can be decrypted
Hello!I am using GnuPG 1.4.x to symmetrically encrypt files before I transfer them to "the cloud" for backup reasons.Is there any way to test these encrypted files for errors, i.e. to make sure they can be decrypted correctly without actually having to decrypt them again?Providing the passphrase again etc. is no problem, I only want to avoid to write the whole file to my disk a third time (unencrypted original, encrypted backup, decrypted test).If I can test the file somehow will I get back an errorlevel on success or error?In short I am searching for something like the test option for packed files that most archivers offer.Thanks Karel___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
