Re: Thunderbird's hints and history for OpenPGP/MIME (new wiki page)
On 03.12.2021 12:04, Bernhard Reiter wrote: First I wanted to gather some feedback, especially about the following section, where I've added a recommendation what to use instead of incompatible header encryption: | Transport information in a decentral network - just like the writing on the | outside of a postal mail envelope - cannot be protected in principle. | When reflecting on this, chose a subject that is plausible in context, | but without sensitive contents, to best veil potential unwanted observers. | (Your thinking is right: The more sensitive this is, the more you have | to build up a plausible context for your unavoidable traces first.) I didn't read the wiki page yet, but I'd like to comment on that paragraph. I agree in part, but not completely. The idea is nice, but can't be realized in practice. From my personal experience, it is very hard and consumes time to find appropriate subject lines. After all, when using OpenPGP in business, recipients invest 5 seconds per message at maximum when scanning the list of received messages to decide what message to read first. "Wrong" subject lines are not helpful in this context. That means that your suggestion may be valid for private communication, but not for business. Rather, it is often good style and really simplifies things if some important (sensitive) data is in the subject line. As an example, imagine that you are communicating with your health insurance company. The staff there usually is very grateful if they see your insurance number in the subject line, plus a few keywords (in German, for example, "Kündigung", "Leistungsantrag" etc.). Not following this convention costs them time and effort and is bad style. Apart from that, you'll have some trouble yourself with that strategy. Imagine you have to find a message you have sent two years ago. That could be hard if you have "faked" the subject lines. Furthermore, the recipient will hopefully answer your message one day, and will typically do this by just hitting the "Reply" button. That means the answer comes back with the same "fake" subject line you originally had chosen, and that game will continue until the communication on this subject has ceased. In the end, you have 50 sent messages and 50 received messages with a "wrong" subject line. Your comparison with snail mail is the right way to understand the issue: Did you ever receive a letter from your health insurance which carried the actual subject on the *outside* of the *envelope* (example subject of a letter from your health insurance: "Payment for your HIV treatment")? I didn't, and I'll have a very serious talk with the sender if I ever do. *Every* piece of data should be protected, especially in electronic communication, except the transportation data which technically is absolutely necessary to get the transport done. In the same way the postal service does not need to know the content of a letter (including the subject) to transport it from the sender to the recipient, SMTP servers do not need to know the subject to transport messages. SMTP basically needs only the sender address (strictly looking at it, not even that, but it is important for bounces and replies) and the recipient address. Sad to say that SMTP servers usually dynamically add headers during transport which already can put somebody at risk, but I guess we'll have to live with that for the moment. A subject line really does not fall into the category of transportation data. SMTP servers don't need to know it to transport the message, and it can (and in most cases, will) contain sensitive data. We shouldn't call something transportation data solely because it is in a header. I am very grateful that we can finally encrypt the subject line with most OpenPGP implementations since several years. Actually, not being able to do this kept me from using PGP (in E-Mail) for a while. Now I always encrypt the subject line, and so do my communication partners. If there are MUAs out there which can't cope with that, refraining from encrypting the subject would be the wrong reaction. Instead, people using such a MUA should be educated to use another MUA. PGP implementations have undergone changes which were much more "breaking" than encrypted subject lines. Best regards, Binarus ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Certified OpenPGP-encryption after release of Thunderbird 78
On 28.05.2020 23:21, Stefan Claas wrote: > > 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. This is not my field, but I believe that (besides authorities) there are companies or other institutions which *must* use certified encryption solutions. Some ideas: - The OP might be employed at a city administration of a small village where the full set of regulations is relevant, but where there is no money (as in many small villages) to buy support. - The OP might be employed at a company like a hospital, a nuclear plant, a company which develops or sells military goods, a law office, a tax office, a (medical) insurance, a bank, and so on - you get the idea :-) While I actually don't know in detail which sort of company is bound by which regulation, I am sure that there are dozens of company types and hundreds, if not thousands of companies which are legally restricted to use only BSI-certified encryption software, especially companies which handle sensitive personal data or which compromise public safety if they let leak data. Even more, since the arrival of the GPDR, each company -even the smallest one- has to put significant effort into protecting personal data, and has to document in detail their respective policies and methods. When implementing the respective concepts and explaining / documenting why they are safe and how they protect personal data, it is of great help when the BSI has certified as many parts of the software as possible. Furthermore, to me, the OP sounds if he is not only employed at a company as a normal user, but as a part-time admin who has been asked to implement the email infrastructure for his colleagues besides his normal work (because the management as usual does not understand the importance and value of such work and the expertise and time which is needed). Regards, Binarus ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Future OpenPGP Support in Thunderbird
On 19.10.2019 17:20, Patrick Brunschwig wrote: > >> Why not stick with that and focus on what has made Enigmail >> successful? > What is the reason in your eyes that made Enigmail successful? > It is the ingenious mixture of integration / ease-of-use on one hand (setting it up (normally) is a no-brainer, including key generation and key upload, it allows for per-recipient rules, it provides a nice GUI for a task which actually is complex, it allows subject encryption, it allows using hardware tokens, it provides PGP/MIME and PGP/inline, and it integrates fantastically; heck, the PGP settings even are integrated into the account settings, exactly where they belong!) and on the other hand the unlimited possibilities of GnuPG (command line, configuration). Last, but not least, we must not forget security issues. Implementing PGP correctly is a hairy task, given the long history of security problems in different implementations. Werner's implementation has an excellent reputation, and it's the only one I personally trust completely. It is exactly the division of tasks which may have contributed to Enigmail's success more than one would imagine. After all, email encryption users do care about the underlying engine. We all know what we would have to expect if the TB team would rewrite the thing itself (which you have ruled out) or would use some library which hasn't been tested as rigorously as GnuPG. Actually, the Enigmail / GnuPG duo is one of the best examples of how different software parts could work together, thus increasing the prevalence of both parts by magnitudes, pushing a technique which the world really needs, and making it usable for the masses. Enigmail / GnuPG is by fare more than its sum. Each of the above reasons has made Enigmail such successful (and GnuPG, or course). Regards, Binarus ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Future OpenPGP Support in Thunderbird
On 16.10.2019 13:07, Patrick Brunschwig wrote: > worry for me. The main problem is the additional complexity that it > brings if you require an external component that you cannot *fully* > control. This covers topics like different behavior of different > versions, but also configuration issues, users rights to install > something on their PC and more. Gpgme may handle some of these issues, > but the fact remains: an external component makes things a lot more > complex, especially for support. I think this is the usual trade-off. One has to put time - either in understanding the APIs and command line parameters of a library / utility, and to keep up with changes, or - in re-inventing the wheel, which in this case for sure will cost much more time and eventually produce catastrophic security breaches and software which is drastically inferior compared to what we have now. After all, everybody uses libraries and utilities. It is just reasonable to have an expert work on a library or utility which uses techniques and mathematical stuff which non-specialists never will understand in detail, and have the non-specialists use that library or utility, instead of letting them re-develop the same stuff, probably introducing all sorts of security flaws and producing inferior software. When I have a bash script under Linux which invokes a compiler using a complicated command line, I wouldn't come to the idea to re-develop that compiler and integrate it directly into bash because that compiler's command line switches could change in the next version ... I am still convinced that re-writing GnuPG (including all functions like hardware tokens, subject encryption etc.) in a secure manner is a hundred times more complex and a million times more error-prone than tracking a few changes to its command line switches or error codes ever could be. Apart from that, there is GpgME, as already has been stated. Regarding the user rights to install software: That was the reason why I thought about bundling the installers and installing both parts in the same directory. Even updates to GnuPG then could be handled by TB's update system (this is only an educated guess - I don't know if the licenses would allow this). If TB would use GpgME, this problem even would not exist in the first place. GpgME would just be another library lying around in TB's installation directory (under Windows, probably a DLL) and for sure could be updated via TB's update system. Just my 2 cents ... Regards, Binarus ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Future OpenPGP Support in Thunderbird
reasonable manner, you have to >> opt-in for a paid contract. For most of us, this is a matter of >> principle. Why should we pay for a thing that used to be free all the >> time? (Note: I don't want to judge that attitude - I am just stating how >> it is). > > > > But "free" email has never been free from the likes of Gmail, Yahoo, > GMX, etc. While you don't pay a yearly fee, you trade your privacy for > a few bucks. You open yourself to tracking and targeted advertising. > Your email is anything but private. A couple years back both Google and > Yahoo claimed to be working on E2EE. I wonder why it never happened? > > The free versions of ProtonMail, Tutanota and Mailfence at least > preserve your privacy. They aren't monetized through advertising and > tracking. Instead they sell premium services to people who want more > capacity or features. Many people I know do email exclusively on their > smart phones. They don't use an MUA and don't care about POP3, IMAP or > SMTP. Their view of using email services in a reasonable manner doesn't > comport with yours or mine. Correct, but (as I wrote) I didn't want to judge the attitude; I just wanted to show how it works. Many users reflexively close web pages immediately as soon as they recognize a $ sign (except online shops and TV / movie / music sites, of course). > I hope I am wrong and Thunderbird's OpenPGP implementation is a complete > success encouraging many more people to encrypt their email. I would, > however, personally prefer that Thunderbird directly implement GnuPG > integration instead of going it alone. That would satisfy both casual > and power users as Enigmail does now. > > Will Thunderbird OpenPGP support smart cards like my Yubikey? How about > a feature like GnuPG's group line or Enigmail's per-recipient rules? > In-line PGP as well as PGP/MIME? Encrypted subject and the ability to > turn it on or off? As far as I know, they are all features of GnuPG or > Enigmail and not required by the OpenPGP specification. > > Patrick and company deserve our thanks for many years splendid service > to the OpenPGP community. So does Werner and his team who created and > maintain a tool that has satisfied a wide range of users for decades. I > doubt that yet another proprietary OpenPGP system is what the world needs. You are speaking out of my heart. Many years ago, I appreciated Mozilla's decision to provide their own root certificates and certificate management, because I trusted them much more than Microsoft. But when it comes to PGP integration, making their own thing for sure is counter-productive. What Werner and Patrick have created is mature and completely trustworthy and surely can't be outranked in the foreseeable time. Not wanting to make users install additional software isn't a reasonable argument for re-inventing the wheel, because AFAIK nothing prevents people from bundling GnuPG with TB in the same installer, and I bet that even installing these two packages into the same directory and letting them use the same registry subkeys technically wouldn't be a problem (I am speaking of Windows here). So why not take Enigmail, integrate it into TB, and bundle Gpg4Win setup with TB setup? All software they ever could develop themselves will be inferior compared to that package, at least in the first time. Regards, Binarus ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Future OpenPGP Support in Thunderbird
On 14.10.2019 09:17, Patrick Brunschwig wrote: > Binarus wrote on 13.10.2019 18:27: > [...] >> 1) The schedule >> >> We have all been educated to update our applications (notably, "internet >> applications" like browser and email clients) as soon as updates are >> available; at least, this is true for security updates. >> >> Despite release plans, I think nobody knows for sure how much time >> actually will pass between TB 72's predecessor and TB 78, and how many >> security updates will be released between these versions. >> >> During that time, I either can't use Enigmail (if I decide to install >> the security updates), or I have to ignore the security updates >> (possibly putting me to risk). >> >> Did I understand this correctly? > > The current stable version of Thunderbird is 68 (and 60 for a few more > weeks); the next stable version will be 78. Users of Enigmail staying on > the stable version of Thunderbird will receive all security updates > until TB 78 will be available. Thunderbird 69 ... 77 are only released > as beta versions that are not intended for end users. > I see. Thank you very much for the clarification. This relieves a lot of tension. Regards, Binarus ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Future OpenPGP Support in Thunderbird
tering, action filters (automatically moving certain messages in subfolders) and so on, all managed at one place, public folders, shared folders and so on). 4) I doubt that these services can be legally used by businesses in Germany. We are having some weird rules here, one of them saying that we have to keep *each* (electronic) message we are receiving and sending in a separate archive where users don't have access to. That is, users of course may do anything they want in their normal email account, but all messages which are ever sent or received must first be copied somewhere where they cannot be manipulated or deleted. I can't imagine how this could be achieved when using those services. These are only a few of the many reasons against using a purely cloud-based email system. Regards, Binarus ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Future OpenPGP Support in Thunderbird
On 13.10.2019 18:51, Werner Koch wrote: > On Sun, 13 Oct 2019 18:27, Binarus said: > >> keys' IDs were formally wrong so that key servers didn't accept the >> keys. The easiest possible solution was to re-generate these keys using > > For the records: Not /keyservers/ but one specific keyserver which runs > on a not yet matured enough code base and is thus expected to have bugs. > Thank you very much for your remark. Actually, I have meant this to be just an example for the problems to expect if too many features are missing. Secondly, I suspect that there are more keyservers out there (running other software) which also would reject those keys (I didn't try, though, so this is speculation). Thirdly, this is the keyserver which is preset in Enigmail (I didn't change the default). For naive users like me, it is not possible to check a keyserver's software version and to analyze how mature / stable it is. I even wouldn't come to that idea, because this is the default keyserver in a well-known software package :-) If I wouldn't have been able to generate correct keys / IDs using GnuPG directly, I eventually would have given up on encryption. Regards, Binarus ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Future OpenPGP Support in Thunderbird
On 08.10.2019 09:08, Patrick Brunschwig wrote: > The Thunderbird developers have announced that they will implement > OpenPGP support in Thunderbird 78 [1]. Support for Thunderbird in > Enigmail will therefore be discontinued. > > [Snip] > > I will continue to support and maintain Enigmail for Thunderbird 68 > until 6 months after Thunderbird 78 will have been released (i.e. a few > months beyond Thunderbird 68 EOL). Enigmail will not run anymore on > Thunderbird 72 beta and newer. IMHO, integrating PGP into TB in general is a good decision. However, I have two concerns (being a naive user, and being far away from understanding the technical aspects). 1) The schedule We have all been educated to update our applications (notably, "internet applications" like browser and email clients) as soon as updates are available; at least, this is true for security updates. Despite release plans, I think nobody knows for sure how much time actually will pass between TB 72's predecessor and TB 78, and how many security updates will be released between these versions. During that time, I either can't use Enigmail (if I decide to install the security updates), or I have to ignore the security updates (possibly putting me to risk). Did I understand this correctly? I am not on a level that I would use GnuPG on the command line to encrypt or authenticate my messages (encryption is fascinating, and if I had the time, it would be a pleasure to dive deeply into this subject, but for the time being, I just need it working), so I am dependent on the TB / Enigmail duo (at least until TB 78). 2) The features When integrating PGP into TB, IMHO great attention must be paid that none of the important features of Enigmail / GnuPG get lost, not even in the first version. The statement that the first implementation probably will be "less feature-rich" than Enigmail (let alone GnuPG) really frightens me and lets me expect all sorts of problems. For example, even I (as a non-advanced user) recently had an issue where I could not use PGP keys which were generated by Enigmail, because the keys' IDs were formally wrong so that key servers didn't accept the keys. The easiest possible solution was to re-generate these keys using GnuPG on the command line (despite my statement above ...) and import them into Enigmail. This simple case shows that we actually need the full functionality of a mature software package like GnuPG from the beginning on (note that my problem was ridiculously simple, but even then I couldn't easily solve it using Enigmail alone). My feeling is that TB (and probably email encryption / authentication per se) will lose a lot of users (including me) if the first implementation lacks essential features, makes the encryption setup fail due to common problems (like mine), or makes encryption unusable or difficult in any other way. By the way, being able to encrypt the subject of an encrypted message also is one of the essential features (thanks, Patrick, and thanks, Werner, that you finally have made this possible a while ago!) ... Just my 2 cents ... Regards, Binarus ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: keys.openpgp.org not sending confirmation email
On 19.09.2019 12:31, Stefan Claas via Gnupg-users wrote: > Binarus wrote: > >> IMHO, this system lacks a mandatory unique token in the key ID. The >> natural choice for such a token would be the email address, because in >> the first place it is the only thing you know for sure when writing a >> private message to somebody else who you haven't become acquainted with >> yet. Perhaps Governikus should think of making it mandatory. > > Well, I was not clear enough, sorry! In order that Governikus can send > you the signed key back it requires that you have an email address in > your UID. I see. That makes much more sense. Thank you very much again! Regards, Binarus ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: keys.openpgp.org not sending confirmation email
On 18.09.2019 17:30, Stefan Claas via Gnupg-users wrote: > Binarus wrote: > >> You have stated that my real name must be in the key ID if I would like >> to have the key certified by Governikus. Does the key ID need to have >> other personal data in it? After all, as an example, there for sure are >> at least 1000 people in Germany whose name is "Peter Meier" (which is >> the reason why I personally will always use the email address (instead >> of the name) as the criterion when searching for a public key). If there >> is other personal data in the ID (like the address), what happens when >> people relocate? > > AusweisApp reads your personal data from your ID-card and then Governikus > certifies your key, containing your real name. Your key does not need to > have other personal data besides your real name. > > My UID for example looks like this: Stefan Claas *offline key* > > > I know that there is as second Stefan Claas living in Germany, but > he will not have the same email address like I have. So people looking > up key servers could then find of course (if he would upload a key too) > a second Stefan Claas. > > I have no expierence when one relocates, but as I see it it does not matter > as long as you are a holder of a German ID-card. > > When in doubt always give a hint to your key in your email signature, > so that people you are communicating with know the proper key to fetch. OK, that makes sense. Thank you very much for the explanation. My question regarding the relocation was only meant for the case that Governikus would need other personal data besides the name (e.g. the address) in the ID to certify a key. So the real name is the only mandatory part in the ID of a key certified by Governikus, while other parts, notably the email address, are optional. Perhaps this policy is too relaxed. Personally, I always include the respective email address(es) in my keys' IDs, but some others probably don't (if they aren't forced to). IMHO, this system lacks a mandatory unique token in the key ID. The natural choice for such a token would be the email address, because in the first place it is the only thing you know for sure when writing a private message to somebody else who you haven't become acquainted with yet. Perhaps Governikus should think of making it mandatory. Regards, and thanks again, Binarus ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: keys.openpgp.org not sending confirmation email
On 17.09.2019 21:58, Stefan Claas via Gnupg-users wrote:
> Binarus wrote:
>
>> Actually, I currently don't know anybody who I could ask to sign my
>> keys, and furthermore, the problem is bigger the other way around. Can I
>> trust the key which I found on the key server for the intended
>> recipient's email address? Can I at least be sure that the key server
>> has sent a confirmation email to that email address and has received the
>> answer? Or has it failed to do so due to a malformed email address, but
>> finds that address nevertheless because it performs a full-text search
>> against the key IDs?
>
> If you would use your real name in your UID you could let Governikus
> certify your key. Governikus is a German CA run on behalf by the BSI.
>
> For that you will need a (certified) ID-card reader and AusweisApp2.
>
> https://pgp.governikus.de/pgp/
Thank you very much for that hint. That might be a solution for German
citizens, and probably the citizens of a few other European countries.
However, I see several problems:
- People just refuse spending money or precious desk space on chip card
readers. The best proof is the nonsense the German banks are currently
doing to implement PSD2. I do not know anybody who has bought a chip
card reader. Instead, everybody installs a TAN generator app (one for
each bank) on the very same smart phone where the actual banking apps
are running, which undoubtedly decreases security.
- While I have no problem with one-time investments (chip card reader),
my red line are regular payments. From a first quick look at the website
you mentioned, I got the impression that the certification is currently
free of charge. However, at a first glance, I couldn't find out how long
a certification is valid, and experience tells me that they will begin
to charge a substantial amount of money every year or so to refresh the
certifications as soon as more than an infinitesimal number of people
use them.
- After the incidents at the web (SSL) CAs (Symantec, DigiNotar and so
on), I do not trust any centralized certification any more, even if
those incidents happened some years ago.
By the way, when clicking "Öffentlicher Schlüssel für die Beglaubigung"
in the menu at the page bottom of https://pgp.governikus.de/pgp/, you
currently just get an error page ("Es konnte leider nichts gefunden
werden"). This for sure is the best way to generate trust ... Probably
it's exactly what you should expect from a company which acts on behalf
of German government.
- The most important aspect is that I just can't force an addressee of a
private message to get that certification. The addressee might live in
another country where such certification is not available, or he might
refuse to buy a card reader or to get the certification for other
reasons. I don't have any figures (hopefully somebody else has), but I
suppose that no more than 5% of PGP users have a chip card reader.
In contrast, the email verification system for keys is by far less
secure than the Governikus certification, but it is already available,
works in every country and provides at least some level of security
which is by far better than nothing. It just needs to be supported by
making implementation easier, which primarily means eliminating the
ambiguities when deciding what is an email address in the key IDs, which
in turn means making dedicated addr entries mandatory and forbidding to
treat anything outside these entries as an email address; all of this
could be achieved with some small changes of the key ID convention /
specification, which additionally would make parsing the key ID by key
servers much more easy, less error-prone and reproducible.
> Regarding the other questions, it would be IMHO really nice if we
> would have internationally more CAs for GnuPG users, thus one must
> not rely on the classical WoT signatures.
As long as these CAs don't charge money, I totally agree with you
(although I am mistrustful towards CAs as I stated above).
Finally, I've got a question (no criticism, really just a question
because I have absolutely no experience with AusweisApp and the like):
You have stated that my real name must be in the key ID if I would like
to have the key certified by Governikus. Does the key ID need to have
other personal data in it? After all, as an example, there for sure are
at least 1000 people in Germany whose name is "Peter Meier" (which is
the reason why I personally will always use the email address (instead
of the name) as the criterion when searching for a public key). If there
is other personal data in the ID (like the address), what happens when
people relocate?
Regards, and thank you very much,
Binarus
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: keys.openpgp.org not sending confirmation email
valid email addresses (addr) as well, one per line, which are the further email addresses to be associated with the key. That array of lines with valid email addresses (addr) is ended by an empty line. The free text part of the ID starts after that empty line. The free text part of the ID is encoded in UTF-8 and may contain any character except the @ character. Software must not generate IDs other than described above. Key servers must refuse publishing keys with IDs other than described above. Key servers must send a confirmation email to all email addresses (addr) which are in a key's ID, and must not publish an email address as being associated with a certain key until it has received an answer to the respective confirmation email. As far as I have understood, that structure could easily be put into tag 13; no new tag would have to be created (although a new tag for the email addresses (addr) would be a huge improvement). We even could allow the @ character in the free text part of the ID if the key servers would provide two different kinds of search: Search by mail address (addr) (here, the key server is only allowed to match the search string against the dedicated address entries), and search by free text (here, the key server is only allowed to match the search string against the free text part). As a final note, I am aware that many problems with scams can be prevented by mutual key signing or by publishing keys on web sites. But to be honest, I don't know many people who have their PGP / GPG keys signed by a noteworthy number of other people. Meeting others just for this purpose is painful, and validating the other party correctly is only possible with some knowledge. And of course, not every private person has a web site, and only a few companies publish more than one email address with its public key on their web site, even if they have dozens of employees with have PGP / GPG installed. Actually, I currently don't know anybody who I could ask to sign my keys, and furthermore, the problem is bigger the other way around. Can I trust the key which I found on the key server for the intended recipient's email address? Can I at least be sure that the key server has sent a confirmation email to that email address and has received the answer? Or has it failed to do so due to a malformed email address, but finds that address nevertheless because it performs a full-text search against the key IDs? So, in summary, my point is that there should be as few restrictions on the ID as possible, but it should be made sure that everything which resembles an email address (addr) and which could be found by querying a key server actually has been validated by having sent a confirmation email and having received an answer. This especially means that email addresses (addr) can't be part of surrounding free text, because parsing (and possibly removing) them from such an environment is technically complicated, implementation-wise error prone and subject to different interpretation. There is some risk that the confirmation / validation failed due to a malformed or wrongly interpreted addr, but that this addr can be found nevertheless on the key server. Therefore, we need to structure the ID so that there is one dedicated place where addrs can be stored and easily parsed, which again means to disallow them in normal free text. Just my two cents - and being happy and grateful for what we have already! Maybe it's too late - having had a long day ... Regards, Binarus ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: keys.openpgp.org not sending confirmation email
On 17.09.2019 15:08, Vincent Breitmoser wrote: > >> but as far as I have understood my communication with Vincent, it's such IDs >> which are a problem for keys.openpgp.org. > > Right, that's because we currently use an actual rfc2822 parser on > keys.openpgp.org. This works fine for *most* users, but in the end causes more > trouble than it's worth, so we will probably switch to something more lenient > soon. > > See also dkg's thoughts on the matter on the openpgp-wg mailing list, to align > the specification with reality: > https://mailarchive.ietf.org/arch/msg/openpgp/wNo27-0STfGR9JZSlC7s6OYOJkI Thank you very much for the link. That was an interesting reading. There are much more differences between IDs in the wild and RFC2822 than I ever would have suspected. Did I get this right? That post has been published just yesterday? Glad that I noticed this just in time - I already was typing "Does anybody know how widespread those proposals are, and which one has won?" :-) Regards, Binarus ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Automatically delete old keys from servers
On 17.09.2019 15:12, Daniel Bossert wrote: > Hi all > > On the key servers are many old keys lying around which aren't valid > anymore. > > Could you implement a function on the servers which delete keys after > let's say one year automatically,reminding the user via email one month > ahead to reupload the keys? > > Me too have some old, useless keys there and people shouldn't use an > invalid public key anymore. I am far from being an expert, but I think that the usual way to deal with this problem is to revoke the key in question and upload the revocation to the key server. Maybe I have missed some basics here and that I am completely wrong, but this at least is what Enigmail proposes if you revoke a key in its key management window: Upload the revoked key. There is a second solution to your problem: Limit the validity of the key when generating it. You can easily generate keys which are valid exactly one year from the date of generation. Any reasonable MUA will refuse to encrypt a message using an expired public key, or will at least show a warning. That way, you can get close to the behavior you want. Your key expires after a year, and although it still remains on the key server after that time, nobody will use it to encrypt a message to you. Furthermore, if memory serves me right, your public key is needed to check your signature; remember that signing works in the opposite direction than encrypting (signing means: you encrypt a message hash with your private key, the receiver decrypts the hash using your public key and checks if the decrypted hash matches the message). So deleting public keys from a key server might be a bad idea anyway. Regards, Binarus ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: keys.openpgp.org not sending confirmation email
At first, thank you very much for your explanations! On 17.09.2019 12:17, Werner Koch wrote: > On Tue, 17 Sep 2019 09:12, li...@binarus.de said: > >> I am asking myself why Enigmail doesn't. I am not sure (and can't test >> at the moment) how GnuPG would behave if given a problematic name when >> generating a key; I hope it would give a warning or would add the > > gpg generates such a key just fine: > > gpg --quick-gen-key "foo, bar | baz " > > results in > > pub rsa3072 2019-09-17 [SC] [expires: 2021-09-16] > D5A13F45AD29FAD517FEB157F29010625F3EDDDA > uid foo, bar | baz I really hope that I don't annoy anybody (being in no way an experienced user in this field and probably still missing many basics), but as far as I have understood my communication with Vincent, it's such IDs which are a problem for keys.openpgp.org. When I first used Enigmail to generate and upload a key with such an ID to keys.openpgp.org, I never got the confirmation email. When I uploaded that key using the web form (https://keys.openpgp.org/upload), it told me that it couldn't parse the key's ID as an email address. Consequently, it couldn't send a confirmation email, and the key, although having been stored on the server, could not be found when being searched for by mail address. > and gpg's internal mail-addr extraction function simply looks for the > left angle bracket to find the mail-address and then checks whether that > mail-addr is valid. Thank you very much for that insight. > The code also allows for a user-id consisting only > of the mail-addr without the angle brackets. This is the way I am going now. After the bad experience, I have decided to use only key IDs consisting solely of the actual mail address hereafter (with or without the angle brackets - I can live with both variants :-)). Enigmail refuses to generate such keys (it insists on entering a non-empty name and doesn't complete the key generation process otherwise). But I could easily generate such keys using the GnuPG command line interface. > The reason for this is > that this de-facto standard only resembles an rfc-822 address but is not > necessary valid. For example due to the utf-8 encoding. I see. Then the problem might be due to standards which are "only" de-facto, leading to parsers (on the key servers) which interpret those IDs subtly differently from what GnuPG / Enigmail and friends expect. By the way, I did not test yet how keys.openpgp.org would behave when given a key ID with a comma in the name, but with the name quoted. In every case, I am happy now, as long as IDs consisting only of the actual mail address remain allowed. Personally, I currently don't need to have my name or other fancy text in my keys' IDs. I suppose that somebody who wants to write me an encrypted message will search for my public key at first by email address (and not by other criteria). At least, I would do so ... Regards, and thanks again, Binarus ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: keys.openpgp.org not sending confirmation email
On 16.09.2019 12:58, Claus Assmann wrote: > On Mon, Sep 16, 2019, Binarus wrote: > >> Surname, Forename | Company > >> Commas are not allowed as part of email addresses. While I knew that, I > > unless quoted, e.g., > "Surname, Forename | Company" Thanks, Claus, for the clarification / correction, and for your continuous support and expertise. Additionally, I just did a quick test. Using Thunderbird, I sent two messages to somebody else, one from an account where the name contained a comma and another one from an account where the name only contained [a-zA-Z] and spaces. Interestingly enough, Thunderbird did its thing right, at least in generating the "FROM:" line. It wrapped the name in quotes in the first case and left away the quotes in the second case. In other words, the receiver got two messages with "FROM:" lines which were formatted differently: FROM: "Surname, Forename | Company" FROM: Forename Surname So Thunderbird seems to add the quotes automatically if necessary, and I am asking myself why Enigmail doesn't. I am not sure (and can't test at the moment) how GnuPG would behave if given a problematic name when generating a key; I hope it would give a warning or would add the quotes automatically. >From a quick glance at the web API (VKS interface) and at the HKP >implementation of keys.openpgp.org, I got the impression that there isn't a >status code or return value from which tools like Enigmail could see that >there was a problem with parsing a key's ID. Perhaps the extended status codes >in the HKP protocol could be used to return that sort of error, but even that >is questionable, and I guess that this is not implemented anywhere. In other words, the key server currently is not able to report such errors when a key is being uploaded via HKP or the web API. Am I correct here? If yes, should we consider this a design flaw in these key server APIs? After all, tools like Enigmail then wouldn't have the chance to report such errors to the user when trying to upload a key. Vincent, could you eventually elaborate a bit on that problem? If we only would be able to read every RFC which affects any software we use for our daily work ... Regards, Binarus ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: keys.openpgp.org not sending confirmation email
On 14.09.2019 13:15, Binarus wrote: > I have used the Thunderbird / Enigmail / Gpg4Win troika for quite a > while without any issue. Yesterday, I had to reinstall, and while doing > so, upgraded to the newest versions of that packages, and while I was at > it, revoked my old (1024-bit) keys and generated new (4096-bit) ones > (using Enigmail's key management). > > So I got four new key pairs, each of them associated with exactly one > email address. I uploaded the four public keys, again using Enigmail's > key management, to Enigmail's default key server, keys.openpgp.org. > Enigmail reported success each time. > > I got confirmation emails for three of that four keys, but it seems that > the key server isn't in the mood to send a confirmation email for the > fourth. I have uploaded that one multiple times since then (again via > Enigmail's key management), each time getting a success message, but > still getting no confirmation email. The issue is solved now. I am documenting the solution for people who are affected by the same problem and find this thread when searching. Credits go to Vincent Breitmoser who has confirmed my own suspicion and who was very helpful and fast with his support. The point is that the key server failed to parse the key's ID as an email address. The ID had the following structure (not the real ID, just to make clear the structure): Surname, Forename | Company Commas are not allowed as part of email addresses. While I knew that, I made the wrong assumption that only the part between the brackets would be considered the email address, and that I could use any characters for the "name" part (expect brackets, of course ...). Obviously, I was wrong, and the name part must obey the same rules as the actual email address. Vincent has told me that a certain number of other people had the same problem, so they are thinking of making their parsers less strict, as far as it concerns the name part. After my correspondence with him, I think that they will be quite fast in implementing the changes. However, I recommend everybody to make their whole key ID match the rules for email addresses if they intend to upload it to a key server. Personally, I have revoked all four of the new keys and generated new ones with the ID being only the email address without a name part. While this was not possible using Enigmail (because Enigmail insisted that I had to add a name to the key), it was very easy by using gpg directly on the command line (by the way, its documentation is quite good). As a last tip, keys.openpgp.org offers to upload a public key directly. When you do that, it will emit helpful messages in case of failure. In my case, with the problematic key / ID, it clearly told the the ID could not be parsed as an email address. Unfortunately, I didn't know about the direct upload offer before asking here ... Regards, and thanks again, Binarus ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: keys.openpgp.org not sending confirmation email
Dear Vincent, On 14.09.2019 14:58, Vincent Breitmoser wrote: >> I got confirmation emails for three of that four keys, but it seems that >> the key server isn't in the mood to send a confirmation email for the >> fourth. I have uploaded that one multiple times since then (again via >> Enigmail's key management), each time getting a success message, but >> still getting no confirmation email. > > keys.openpgp.org admin here! Can you please contact supp...@keys.openpgp.org > from the address in question? I'll try to help you from there, if we tried to > deliver mails there will surely be something in the logs or bounces. > Thank you very much for your fast reply! I have sent an email from the address in question to supp...@keys.openpgp.org as you have advised. I am looking forward to what (silly thing) I have done wrong ... Again, thank you very much for your support and time. Regards, Binarus ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
keys.openpgp.org not sending confirmation email
Dear all, at first, thank you very much for providing privacy and safety for such a long time free of charge to us! Second, the following question could be slightly off-topic because it is partly about the behavior of a key server which clearly is not part of the GPG software. However, I think I have done something bad to my Gpg4Win configuration, so I hope I don't get flamed. I have used the Thunderbird / Enigmail / Gpg4Win troika for quite a while without any issue. Yesterday, I had to reinstall, and while doing so, upgraded to the newest versions of that packages, and while I was at it, revoked my old (1024-bit) keys and generated new (4096-bit) ones (using Enigmail's key management). So I got four new key pairs, each of them associated with exactly one email address. I uploaded the four public keys, again using Enigmail's key management, to Enigmail's default key server, keys.openpgp.org. Enigmail reported success each time. I got confirmation emails for three of that four keys, but it seems that the key server isn't in the mood to send a confirmation email for the fourth. I have uploaded that one multiple times since then (again via Enigmail's key management), each time getting a success message, but still getting no confirmation email. I am absolutely sure that this isn't some spam-filter-related issue or similar. I had a look onto what the MX for the email address in question was logging when uploading the key. I did this several times, and each time I watched the logs at least for five minutes after having uploaded the key. No email message from the key server arrived. I have carefully checked multiple times that there is no typo in the email address which is associated with the key in question. And as expected, when searching for the first three keys on that key server, they are found, while the fourth is not found. Now I fear I have done something silly to the Gpg4Win settings (although I haven't changed its configuration by intention), and I hope that somebody could explain what could have gone wrong here. I have quite a good idea of how PGP encryption works in general, but I never (until now) have used GPG's command line interface (just hadn't to do so because Enigmail did its job quite good), so it would be nice if the issue could be explained in simple words :-) Thank you very much in advance, Binarus P.S. If it would help, I wouldn't have a problem with publishing the email address and the public key in question here. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Changing PINs of German bank card
On 15.07.2017 11:17, Andy Ruddock wrote: > Just as a point of interest > >> I am not sure if this is an intentional limitation of the cards (to >> prevent users from choosing idiotic pins like 1234 or their birthday). > > I know of somebody who had 1234 issued as their PIN for a UK bank > account (it IS as random a selection as any other 4-digit number). Yes, in a mathematical sense. Taking the human factor into account, that person has been very unlucky. If you are interested in the details, please refer to my post from 2017-07-12 08:09. Regards, Binarus ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Changing PINs of German bank card
On 15.07.2017 16:40, MFPA wrote: > > > On Thursday 13 July 2017 at 7:18:41 AM, in > , Binarus wrote:- > > >> I don't think so. Banking chip cards contain >> mechanisms for local PIN >> verification. You can see that an ATM (or the card) >> immediately decides >> if the PIN is correct or not even if the ATM's >> network connection is >> failing at that moment. > >> Banking chip cards furthermore contain a processor >> and software for >> cryptographic operations, so that the endless >> capabilities of modern >> cryptography are at hand. Think of asymmetric methods >> like RSA ... > > All of which is irrelevant for online transactions. On the shopping > website, the customer keys in the long card number, the PIN, and the > last three digits from the signature strip. The chip on the card is > not involved. > > If a website would try to query my EC card's PIN, I would go to the police. Maybe the situation might be different in other countries, but I have never entered any card number into a shopping website with the following exception: If paying via credit card (VISA and the like), the website queries the credit card's number (I think this is what you mean by "long number"), and *may* query additional three digits from a number which is on the back side of the card (near the signature strip, as you described). Customers here in Germany can activate additional security for VISA cards (I don't know about other ones): If this is enabled, you have to enter an additional TAN (*NOT* PIN) besides the credit card number and the three digits when doing the payment. The TAN will be sent to your mobile phone. Perhaps it's that what you were referring to? I know that there are combinations of credit and EC cards. In this case, the card *will* have a chip integrated (at least the newer ones). But still then, a shopping website must not ask for the PIN (which is only related to the EC card part). After all, you can't pay anything on a shopping website directly by EC cards (or the EC card part of a combined credit and EC card). At least, I never saw such a thing here in Germany (and I am doing a lot of online shopping). The reason for the latter is that the PIN should *never* be transferred or be known in clear by any party (besides yourself and perhaps your bank, but see my previous posts for my opinion about that). The only method to pay by EC card would be using a certified card reader (which handles the payment safety independently from your PC). But since no consumer is ready to pay a lot of money for such a card reader, that payment option just does not exist when shopping online (at least, not here). Regards, Binarus ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Changing PINs of German bank card
On 15.07.2017 12:36, MFPA wrote: > > > On Wednesday 12 July 2017 at 11:01:35 AM, in > , Binarus wrote:- > > >> As far as I know, no bank will be able to tell you >> your PIN if you have >> forgotten it > > They can in the UK. For example, see > <http://personal.natwest.com/personal/ccet/service/debit-card0.html> > and > <https://www.barclays.co.uk/help/cards/pin/forgot-pin/#main>. > That is interesting. I wouldn't have expected that. Perhaps somebody who is in cryptography deeper than me could comment if it is dangerous. And perhaps somebody who has accounts with multiple German banks could tell us if this is possible with one of his banks as well? I am having all accounts with the same bank ... Regards, Binarus ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Changing PINs of German bank card
On 13.07.2017 01:19, MFPA wrote: > > > On Wednesday 12 July 2017 at 6:51:42 AM, in > , Binarus wrote:- > > >> and this means that such software would >> have to run on the >> card. > > Or The ATM. You are right. The ATM will get hold of the PIN in clear in case the user wants to change it, because the user has to type it then. The ATM theoretically could check the PIN for certain criteria in that moment, and refuse it if appropriate. > But maybe chip and PIN cards have the capacity. > Wherever it might run: I never have heard about a bank having implemented such checks ... Regards, Binarus ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Changing PINs of German bank card
On 13.07.2017 01:23, MFPA wrote: > > > On Wednesday 12 July 2017 at 3:15:09 PM, in > , Binarus wrote:- > > > >> (if the >> PIN needs to be >> stored at all in some backend which I doubt). > > The Bank must know the PIN (or a hash). Otherwise they would not know > if you entered the correct PIN for online transactions. I don't think so. Banking chip cards contain mechanisms for local PIN verification. You can see that an ATM (or the card) immediately decides if the PIN is correct or not even if the ATM's network connection is failing at that moment. Banking chip cards furthermore contain a processor and software for cryptographic operations, so that the endless capabilities of modern cryptography are at hand. Think of asymmetric methods like RSA ... Regards, Binarus ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Changing PINs of German bank card
On 12.07.2017 12:10, Peter Lebbing wrote: > On 12/07/17 07:51, Binarus wrote: >> Furthermore (not being sure, so read with care), I think that the bank >> does not know your pin > > When my bank card is replaced because its validity is about to end, the > new card has the same PIN as the old one. I can't readily think of a way > to do that without the bank knowing my PIN, since the new card didn't > physically exist yet when the old card got its copy of the PIN.[1] See https://security.stackexchange.com/questions/62306/a-second-bank-card-arrived-with-the-same-pin and https://security.stackexchange.com/questions/88711/how-can-my-bank-issue-a-new-credit-card-with-the-same-pin-number > Furthermore, I see no use to the bank not knowing my PIN. If their > backend got hacked, these random 4 digits being public knowledge are the > least of the problems. > > And since a pin has so low entropy, I don't see how to protect it with a > hash. Any system that can verify correctness in the time it takes to do > a PIN payment[2] can do 10,000 guesses in reasonable time. Right, but no reason to not do it that way (if the PIN needs to be stored at all in some backend which I doubt). > Also, back when you could do payments with the magstripe (which, AFAIK, > can still be done in some countries, using your Dutch bank card, if you > allow it), the PIN necessarily went to the bank, there was no way for a > check by the chip in the card. I never did look into the magstripe technique ... so no clue here. I only know that those cards could be copied easily. > Anyway, I'm still writing this even though I questioned its usefulness. > But let's consider whether this thread really needs to go on much > longer, it seems it has run its course and is now turning into a wide > trickling delta that is no longer hurrying towards its destination but > rather seeking the path of least resistance in any random direction :-). You are right - let's finish. Regards, Binarus ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Changing PINs of German bank card
On 12.07.2017 12:27, NdK wrote: > Il 12/07/2017 12:01, Binarus ha scritto: > >> Not sure about that. Similar to serious websites which don't store your >> password in clear text, but do store the password's hash instead, I >> would expect that banks don't store your PIN in clear text as well. > Even with 6-digits PIN it would take *seconds* to an attacker to brute > force hashed PINs once he gets the hashed database. [...] While this is correct, it is no reason for not doing it that way (if we choose to ignore the endless possibilities cryptography offers and decide to store the PIN in some form in a backend at all). Salted hashes would > multiply the needed time by the number of PINs (approx). > So keeping such a database would be a really stupid thing to do -- > unless it's kept in a HSM. Of course, I was talking about salted hashes. Besides that: https://security.stackexchange.com/questions/88711/how-can-my-bank-issue-a-new-credit-card-with-the-same-pin-number https://security.stackexchange.com/questions/62306/a-second-bank-card-arrived-with-the-same-pin Some comments / answers in the first one claim that the PIN might be stored in hashed form in some database. Most comments / answers in the second one claim that the PIN is stored on HSM (they don't seem to be sure if it is in clear text or encrypted there) (if I had more time for research, I probably had found better explanations ... the two links basically were on the first result page on Google when searching the respective keywords). But whatever: My key point was that the PIN *never* is stored (or transmitted) in clear text outside an HSM, meaning that software which could examine the PIN according to certain criteria will have to run inside that HSM. I do not think that any bank has implemented such a thing. Regards, Binarus ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Changing PINs of German bank card
On 12.07.2017 11:42, Guan Xin wrote: > On Wed, Jul 12, 2017 at 1:51 PM, Binarus <mailto:li...@binarus.de>> wrote: > > On 11.07.2017 20:38, MFPA wrote: > > > > > > On Tuesday 11 July 2017 at 8:44:48 AM, in > > <mailto:mid%3a3499376d-11fb-9854-688a-48e054166...@binarus.de>>, > Binarus wrote:- > > > > > >> I am not sure if this is an intentional limitation of > >> the cards (to > >> prevent users from choosing idiotic pins like 1234 or > >> their birthday). > > > > > > Surely things like 1234 can be prevented by software. > > > > But birthdays and the like probably not. > > Furthermore (not being sure, so read with care), I think that the bank > does not know your pin, but it is stored in the banks' backends as some > sort of hash, and this means that such software would have to run on the > card. > > Such software can run on ATMs if that are the only places where one can > change the PIN. > And I don't think the bank needs the hash of the PIN. They may need the > hash of the key(s) protected by the PIN, however. Not sure about that. Similar to serious websites which don't store your password in clear text, but do store the password's hash instead, I would expect that banks don't store your PIN in clear text as well. As far as I know, no bank will be able to tell you your PIN if you have forgotten it even if you go there and show them your passport. They can only generate a new one (or a new card), but they can't tell you the existing one because they just don't know it. That means that the bank's backend will never see the PIN you choose and thus can never decide if it is insecure (i.e. something like ). If a bank decides to handle the PINs that way, they probably won't allow the ATM to get hold of the PIN in clear text as well. I might be wrong, though. Regards, Binarus ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Changing PINs of German bank card
On 11.07.2017 21:09, Matthias Apitz wrote: > Why 1234 is an idiotic PIN? What are idiotic PINs? Of course, idiotic is > any PIN which has in your pocket hints about this (like a sticker attached > or your birthday). But remember, you normally have 3 tries only to test > all "idiotic" PINs. 1234 is same idiotic as 2345 or as 3456 or or as > , or , or ... According to my understanding, the most idiotic PIN exactly is the one with the highest probability of being guessed, in other words, the one that is most often used by other people as well. You are right in a mathematical sense, but you leave out the human factor. If all people would choose their PINs freely, PINs for sure were not equally distributed. 10% of the pins would be , another 10% 1234, another 30% their owner's birthday and so on. A little bit of statistics (your name sounds German): http://www.sueddeutsche.de/wissen/unsichere-pin-codes-erwischt-1.1486312 I don't have time for a thorough research right now, but this article gives us an idea. I don't think the situation has changed much since 2012 ... Regards, Binarus ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Changing PINs of German bank card
On 11.07.2017 20:38, MFPA wrote: > > > On Tuesday 11 July 2017 at 8:44:48 AM, in > , Binarus wrote:- > > >> I am not sure if this is an intentional limitation of >> the cards (to >> prevent users from choosing idiotic pins like 1234 or >> their birthday). > > > Surely things like 1234 can be prevented by software. > But birthdays and the like probably not. Furthermore (not being sure, so read with care), I think that the bank does not know your pin, but it is stored in the banks' backends as some sort of hash, and this means that such software would have to run on the card. Regards, Binarus ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Changing PINs of German bank card
On 11.07.2017 14:38, Jerry wrote: > On Tue, 11 Jul 2017 12:32:56 +0200, Binarus stated: > > [...] >> I am not completely sure if I got you right. Wouldn't that mean that I >> have to lose my card, the bad person then makes two guesses, then I get >> back my card and enter my correct pin, then I lose my card again, and >> the same bad person finds it again and makes another two guesses, then >> I get my card back again and so on? > > If you continually lose your card that often, you have more problems > than just a lost/stolen card to deal with. I sincerely hope you are > never trusted with confidential information. > Not sure if you eventually have misunderstood me. I was just trying to understand the previous speaker by asking him what exactly he was meaning ... >> The only way to abuse the fail counter reset feature would be to steal >> the card, to copy it and to return it to its owner, and to do this in a >> way that the owner would not notice it. But again, the adversary would >> then still have to observe the card owner to see when the counter is >> reset and to start his next tries. > > I was told, although not confirmed, that cards with embedded chips > cannot be copied and still be usable. If anyone would like to comment > on that, it would be welcomed. No idea about the U.S., but talking about Germany: The main problem with ATMs here is skimming (I am not sure if this wording is correct in the U.S., so let me shortly explain: Skimming means that some adversary manipulates an ATM in that he mounts an own user interface onto it, perfectly imitating the original interface (mechanically - own electronics, own keyboard), intercepting the data stream and the keystrokes (pin), or mounts a pinhole camera to record people entering their pins)). AFAIK, at least until one or two years ago, the skimmers used to copy the cards, but recently banks upgraded their ATMs and their customers' cards so that they can't be copied any more. But for compatibility, the ATMs still won't refuse old cards which can be copied. But please don't take this as bare truth; I am really not sure. >>> The probability to guess the correct code during the 5-years life of >>> the card is definitely non-negligible.> >>>> And there is one more very important thing most people don't think >>>> of: What happens if you have an accident or if you die? Your heirs >>>> will have all sorts of troubles if something happens to you and >>>> they can't access your electronic accounts because they don't have >>>> the passwords. >> >>> Usually there are other, non-technical ways. For example they just >>> go to the bank with a death certificate. > > I have actually seen that happen. The estate lawyer had to fill out > some paper work, but it was really no big deal. Basically, it is the > same procedure used to get access to a deceased safe deposit box. No chance to have it that ease here in Germany ... at least with certain banks. >> I already have seen cases where it was not that easy in Germany. >> Usually, presenting a death certificate to the bank is not enough. I >> have seen that the bank had to make sure that the people presenting the >> death certificate actually were the legal heirs. That meant that those >> people had to acquire all sorts of documents from all sorts of >> authorities which has been very expensive (several hundreds of EUR), >> but more important, was very unpleasant and time consuming, especially >> in the situation they were. > > Good for them. They should make absolutely sure before releasing the > funds. I agree. >> AFAIK, there is only one thing you could do to avoid that hassle: The >> testator and the heirs should make a contract of inheritance. Such a >> contract must be made by a notary, so this will also have its cost, but >> when you present such a contract to the bank (in addition to the death >> certificate), you will have no problems. > > The cost of a notary is a few dollars; therefore, negligible. Honestly, > I would hope that it would NOT be that easy. Here in Germany, a notary even won't take his pencil without earning a significant amount of money. As far as I can remember, the inheritance contract did cost about 500 EUR (about US $560) many years ago, but that was still a small amount of money compared to the hassle the heirs would have had if they did not have that contract. By the way, there is no competition in this field because the money a notary charges for an action is defined by law. There is a detailed catalogue which lists every action a notary could (may) do, even the most exotic ones, and how much money he will get for that
Re: Changing PINs of German bank card
On 11.07.2017 11:48, Matthias Mansfeld wrote: > On 11 Jul 2017 at 9:44, Binarus wrote: > >> On 10.07.2017 17:42, Guan Xin wrote: >>> This is probably a general question -- >>> >>> I have never seen a German bank that allows changing the PIN of a card. >> >> I am not sure if this is an intentional limitation of the cards (to >> prevent users from choosing idiotic pins like 1234 or their birthday). > > [..] > At least Sparkasse and HypoVereinsbank and IIRC also Postbank allow > changing at the ATM terminal. > > And a birthday isn't as idiotic as 1234 or , as long you assume a > standard pickpocket doesn't know you personal data (OK, your ID-card > within the same wallet... maybe no good idea. Then not your own > birthday but from a person or your cat you can remember, or better > your wedding day, which normally would be forgotten always ;-) You are right, but experience tells us (no, not us, but the banks) that people won't think about it. I have no doubt that people like you and me would choose a secure pin, but from a bank's point of view, most people would choose pins like 1234 or their birthday. It might be only a matter of time until there is the first case of a bank refusing to compensate a customer because his pin was his birthday. >> Now, this is a completely different question which does not have to do >> anything with the pin's length. The answer to this question completely >> depends on your environment and your intentions. I will explain this by >> two examples with contrary conclusions: >> >> Example 1: >> > [...] >> >> Example 2: > [..] > > Example 3 > > MY use case would be: I have, let's say two bank accounts at > Sparkasse, one at Postbank, one at HypoVereinsbank (possible reason: > two bussines accounts and one private account and one from a > inherited account) and I can remember ONE good "random-like" > 4-digit-PIN, but would mangle definitely four different PINs (been > there, done that...). Then I chose one and the same "good" PIN for > all four cards which I don't need to write down anywhere and > everything is OK. This is a good point as long as we are discussing only banking card pins. My examples were more general (an electronic password safe will store all sorts of other secrets / web passwords). Since the OP had asked about banking card pins, I eventually should have restricted my answers to that. On the other hand, I can image a bunch of cases where somebody would like to take web passwords (and not only banking card pins) along when going out (e.g. doing web based email in an internet cafe during vacation). In such cases, I think there is no reason why the pins shouldn't be stored in the password safe as well. Thinking about your use case, I am not sure if I would try to make all pins the same, given the fact that nowadays skimming is the main problem (and not stealing and trying to brute-force). I am not sure if banks will compensate if something very bad happens and all four of your accounts get emptied when the respective cards have the same pin. Probably most banks disallow this in their terms of service (AGBs). After all, you don't use the same password for your eBay, Facebook and Paypal account, do you (unfair question, because those accounts won't be disabled after three wrong password entries, but nevertheless ...)? Regards, Binarus ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Changing PINs of German bank card
On 11.07.2017 14:32, NdK wrote: > Il 11/07/2017 12:32, Binarus ha scritto: > >> But now, being a German citizen, try the same thing with eBay, Facebook, >> LinkedIn, PayPal and so on ... no thanks. > Why should heirs have access to social accounts? Paypal, otoh, is a bank > that have to follow the same rules of other banks... Interestingly enough, this subject is becoming more and more important. I think I can remember that there are first tries in some countries (or the EU?) to make respective laws. At least, I am sure that there already were lawsuits where heirs have tried to get hold of accounts of somebody who passed away (in the case I can remember, a facebook account has been subject of the lawsuit, but I can't remember right now how it ended). IMHO, there are many reasons why this should be possible, so I would appreciate if there were such laws. I don't want this thread to become too off-topic, so I won't elaborate on this in a fashion this complex subject deserves, but just give one pragmatic example: Let's suppose somebody offers something on eBay and then passes away. Let's suppose that somebody else wins that auction and immediately pays via PayPal. Now what? There may be means to solve such situations, but they usually cost lots of time, money or nerves, and this has been just a simple example. If we think a while about it, we surely will find a constellation where it would be quite catastrophic if an account holder's heirs couldn't get hold of his accounts. >> Nice ideas :-) My own security needs are not that high, though (hoping >> that life won't punish me for that optimism). > My concern with a singl "cleartext" pass would be a burglar that steals > it together with other valuables... You are right, burglary is a real threat. But if you have memorized your master password and don't keep it on paper in your own apartment / house, but just give it on paper to a relative, the burglar will have to steal the paper from your relative and at the same time steal your PC (or banking card) from you to make anything out of it. Therefore, I have no problem with giving the password on paper to a relative who lives some km away from me. I would never keep the password on paper in the same room (or even building) as the PC or banking card, though, and as soon as either the PC (or banking card) or the password paper would be stolen, I would immediately change the password (and hand the new one out on paper to my relative). >> To add to it, if you mistrust your relatives, you could put the password >> on paper into some sort of lock box and carry the key to that lock box >> with you. But then what would happen if you lost that key? > Given that mechanical keys are often easier to open whithout the key > than with it... Actually, I was thinking about a lock box in a bank or such things ... Regards, Binarus ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Changing PINs of German bank card
On 11.07.2017 10:14, NdK wrote: > Il 11/07/2017 09:44, Binarus ha scritto: > >> - If somebody tries to brute force the pin (or online banking password), >> the access will be permanently denied if there are more than 3 failures >> (the exact number may vary). That means that the length of the pin / >> password is not as important as one might think, because it is >> practically impossible to brute force a 4 digit pin with only 3 tries. > If you routinely use your card twice a day, they can make two or four > guesses each day: every correct PIN you insert resets the counter. I am not completely sure if I got you right. Wouldn't that mean that I have to lose my card, the bad person then makes two guesses, then I get back my card and enter my correct pin, then I lose my card again, and the same bad person finds it again and makes another two guesses, then I get my card back again and so on? This is practically impossible (unless I have missed something obvious). How could the correct pin be entered and the counter be reset if I didn't get the card back? Or did you refer to an adversary who copied the card? In that case, he still would have to know when I actually have entered the correct pin (which would mean that he permanently had to observe me) to start his next two tries. Furthermore, people usually call their bank to make their card invalid as soon as they notice they have lost it. This means that they usually won't enter the correct pin again after having lost the card. The only way to abuse the fail counter reset feature would be to steal the card, to copy it and to return it to its owner, and to do this in a way that the owner would not notice it. But again, the adversary would then still have to observe the card owner to see when the counter is reset and to start his next tries. > The probability to guess the correct code during the 5-years life of the > card is definitely non-negligible.> >> And there is one more very important thing most people don't think of: >> What happens if you have an accident or if you die? Your heirs will have >> all sorts of troubles if something happens to you and they can't access >> your electronic accounts because they don't have the passwords. > Usually there are other, non-technical ways. For example they just go to > the bank with a death certificate. I already have seen cases where it was not that easy in Germany. Usually, presenting a death certificate to the bank is not enough. I have seen that the bank had to make sure that the people presenting the death certificate actually were the legal heirs. That meant that those people had to acquire all sorts of documents from all sorts of authorities which has been very expensive (several hundreds of EUR), but more important, was very unpleasant and time consuming, especially in the situation they were. AFAIK, there is only one thing you could do to avoid that hassle: The testator and the heirs should make a contract of inheritance. Such a contract must be made by a notary, so this will also have its cost, but when you present such a contract to the bank (in addition to the death certificate), you will have no problems. But now, being a German citizen, try the same thing with eBay, Facebook, LinkedIn, PayPal and so on ... no thanks. >> So I tend to write down at least my master password on a sheet of paper, >> put that in a sealed envelope and give it to a relative who I highly >> trust. In case I die, they open the envelope, have the master password >> for my password safe and can use that to open the access to all my >> accounts. Alternatively, you could have some relative you trust memorize >> your master password. But since he won't use it regularly (hopefully), >> he probably will forget it after short time ... > Better use shamir's secret sharing, or just use LCD-segments characters > printed on two acetate sheets that need to be combined to be read. > Obviously the two sheets are to be given to two different people, in > sealed envelopes... Nice ideas :-) My own security needs are not that high, though (hoping that life won't punish me for that optimism). > BTW the method you use is the same that was used for our mainframe's > master password. :) To add to it, if you mistrust your relatives, you could put the password on paper into some sort of lock box and carry the key to that lock box with you. But then what would happen if you lost that key? Regards, Binarus ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Changing PINs of German bank card
ogger will be able to get on your PC (given the latest ransomware attacks, this obviously is a real threat even when you are running an up-to-date virus protection). In this case, using a password safe software won't protect you. The Trojan horse / keylogger could be able to intercept all your keystrokes, including your master password for the password safe. If you don't use a password safe and just store the passwords in an unencrypted text file (perhaps because you are the only person who physically has access to the PC in question), a Trojan horse will be able to read all your passwords even without intercepting keystrokes. So, in this case, it obviously would be better to write down your passwords on a sheet of paper provided you can store that paper in a place where only you have access to (for example, some secret place in your private apartment). >From these examples, it should be clear that there can't be a general recommendation which fits all cases. And there is one more very important thing most people don't think of: What happens if you have an accident or if you die? Your heirs will have all sorts of troubles if something happens to you and they can't access your electronic accounts because they don't have the passwords. So I tend to write down at least my master password on a sheet of paper, put that in a sealed envelope and give it to a relative who I highly trust. In case I die, they open the envelope, have the master password for my password safe and can use that to open the access to all my accounts. Alternatively, you could have some relative you trust memorize your master password. But since he won't use it regularly (hopefully), he probably will forget it after short time ... Regards, Binarus ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: How to join pubring.kbx and pubring.gpg?
On 16.06.2017 14:46, Juan Miguel Navarro Martínez wrote: [..] > If you want to use OpenPGP, tell your partner to make an OpenPGP > certificate using GnuPG or any OpenPGP supported software. You can them > make PGP/Inline or PGP/MIME (if your email client/plugin supports it, > Enigmail does) email. [...] > Enigmail only works with OpenPGP-related keys. > gpg4win is only a suite of GnuPG related software, with GPGSM for the > management of X.509 certs. Kleopatra is only a front-end GUI client for > both OpenPGP and X.509 operations with the respecting GnuPG tools. [...] > As said above, if your partner uses X.509 then use X.509. If you want to > use OpenPGP tell him to make an OpenPGP key. [...] > If he tries to decrypt a PGP/Inline or PGP/MIME message using an S/MIME > client it won't work. He'll need a PGP/Inline or PGP/MIME compatible > software for that (Thunderbird with Enigmail; Claws Mail, Mutt, etc...). [...] > It was announced on the mail-list of Gpg4Win. But you can also find the > Beta directory link in the mid part of "All Downloads" section in the > Download page. [...] > And to reiterate again, Enigmail, as far as I know, will only support > OpenPGP certificate or keys. > Gpg4Win supports X.509 by using the GPGSM CLI tool or Kleopatra as a GUI > front-end but for S/MIME emails I would recommend an email client like > Thunderbird. Again, thank you very much for your time. I have got it now. I will just use S/MIME to communicate with that partner. Please see my previous post for a detailed explanation why I have been worried so much (although it has been clear to me since a long time that S/MIME and PGP are different things). To make a long story short, my partner first asked me if I would like to use PGP or S/MIME (I answered "PGP"), and then claimed that the certificate he provided was a "PGP certificate". Furthermore, I wouldn't have come to the idea that gpgsm handled S/MIME certificates (although I am now understanding why it is named gpg>SM< :-)). In my naive world, GnuPG software (and gpgsm obviously falls into that category) dealt only with PGP, not with S/MIME. Worlds change ... For that three reasons, I did not even consider that the certificate my partner provided could be an S/MIME certificate, but believed that it would be some sort of a "new, modern PGP certificate". If I only had known that earlier ... Sorry for the lengthy posts, and again: Thanks you very much! Binarus ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: How to join pubring.kbx and pubring.gpg?
On 16.06.2017 11:32, Damien Goutte-Gattat wrote: > Well, there is the Monkeysphere's pem2openpgp tool [1], but AFAIK it > only works with *private* keys, not public keys. Most articles / tutorials I came across during my research were dealing with private keys ... that should have made me mistrustful on its own. > No. You would generate an OpenPGP-encrypted message that your partner > won't be able to decrypt using their S/MIME software. They would need an > OpenPGP implementation (be it GnuPG or any other one). This is where I have been mislead. Of course, I already knew that S/MIME and PGP are both widely used, but totally different, and it was also clear to me that a recipient who uses S/MIME has no way to decrypt PGP messages, and vice versa. There were three things which pulled me on the wrong track: 1) My new communication partner claimed that they supported S/MIME as well as PGP, making the impression that I could choose which one I would like to use. I told him that I would like to use PGP (as I've always done in similar cases in the past) and not S/MIME. 2) My new communication partner claimed (even in written form) that the certificate they provided to me was a "PGP certificate". Well, we all probably know the level of technical knowledge in big companies' customer support ... I should have been warned. 3) I would never have come to the idea that GnuPG handles S/MIME certificates. Obviously, gpgsm is part of GnuPG, and obviously, it can handle the certificate which I have been given. Thus, I have been quite sure that it indeed must have been some sort of "PGP certificate", because I couldn't imagine that a part of GnuPG software could deal with S/MIME certificates. So GnuPG seems to be in the process of becoming an S/MIME software, a thing which I would have heavily denied until now if somebody would have asked me. These three reasons made me strongly believe that the certificate I have been given actually was a thing like PGP key in a "modern" format. So I was convinced that I could convert it to the usual PGP key format somehow. (Sidenote: The naming of that utility of course finally makes sense now ... I have done gpgsm and have wondered about the name of that program more than one time :-) > You seem to be confused between OpenPGP certificates and X.509 > certificates, and I think this is the root of your problem. Not at the level of general understanding, but having been heavily mislead in this case (see above) ... > Thunderbird already supports S/MIME and X.509 certificates natively, you > do not need Enigmail for that. Yes, I have configured Thunderbird often in all sorts of environment and therefore often have come across the S/MIME configuration window. So I knew it was in there, but I did not use it until now. The actual cause of my problem, as you have already stated, is quite simple: I just did not know nor assume nor even consider that the certificate I have been given could be an S/MIME certificate. Now that I know that, I am quite confident that I will be able to configure and use S/MIME properly. Once again, a big thanks for all the help and for your time! Regards, Binarus ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: How to join pubring.kbx and pubring.gpg?
At first, I'd like to thank you for the great explanations. On 14.06.2017 19:21, Juan Miguel Navarro Martínez wrote: > As far as I know, GPGSM is a GPG tool to use X.509 certificates. That's > not the OpenPGP protocol. With this said... Here is where my worry begins. AFAIK, all PGP variants are using RSA key pairs. A public X.509 certificate is just a container for such keys (and possibly has information about the certificate chain). Given that, in my naive world, it should be no problem to extract that public PGP key from the certificate; the goal would be to gain the "pure" key which then could be added to the traditional PGP (Enigmail / gpg4win) world. Of course, any information regarding the certification chain would be lost when doing so, but I really wouldn't care about that (I have downloaded the certificate from the website of a very big well-known company; the website is protected by TLS, and I have checked that there was no man in the middle). Unfortunately, I didn't find any hint on how to extract that key. It is in the certificate for sure, and I think I will eventually be able to dump it after playing some time with OpenSSL, but then I eventually won't know how to integrate it into Enigmail / gpg4win. Furthermore, I am still not sure if this is just a matter of transforming the key or if the whole software / data exchange protocol depends on the sort of key. In other words, even if I would manage to extract the key and to integrate it into the Enigmail / gpg4win world, would the communication partner be able to decrypt the respective messages? > For GnuPG to use KBX format, you must have the modern branch which is > 2.1 and later. For that, you need to use the experimental version of > Gpg4Win: This is a very important hint. I didn't even know that such a branch exists. An average user visiting their website mainly for downloading their software won't see any hint regarding that ... or I have missed something. > After you download the experimental version, you must do the follow: [...] > > I must remind you that your partner's key will still be a X.509 key and > so you'll still need to use GPGSM to list, verify messages from and > encrypt message to that key but now both public OpenPGP and X.509 keys > will be stored in pubring.kbx. Thank you very much for the manual :-) So I now know how use pubring.kbx instead of pubring.gpg, but obviously, this is not the solution to my problem (as I initially have thought). The bottom line seems to be that I can't use Enigmail / gpg4win to exchange email with communication partners which provide their keys in form of certificates. This does not make much sense since there is a strong trend among the big companies to provide only PGP certificates instead of PGP keys. Using gpgsm on the command line is not what I would like to in my daily email routine (although I am a strong fan of the command line in other situations). Slightly off-topic: Does anybody eventually know if and when Enigmail / gpg4win will support certificates? Thank you very much, Binarus ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
How to join pubring.kbx and pubring.gpg?
Dear experts, I am running Thunderbird, Enigmail and gpg4win on Windows 7. All components are up to date, and I am using this combination successfully since several years for signing, encrypting and decrypting email messages. Now, for the first time, a new communication partner won't provide his public GPG key directly, but only in form of a .p7b certificate. Since several hours, I am having a remarkably hard time trying to import his public key into the setup mentioned above. 1) gpgsm seems to be the only tool which can be used to extract public keys or convert certificates from the .p7b format to the format needed by GPG. Fortunately, gpgsm is included in the gpg4win package, so I could use it on my system. 2) But whatever I did, I could not see the new public keys in the key list gpg shows. So I tracked the issue further down and noticed: gpg -k correctly lists the keys I have currently in use, but not the new, imported key. gpgsm -k correctly lists the new key, but not the keys I have currently in use. 3) Further research lead me to this post: https://lists.gnupg.org/pipermail/gnupg-users/2015-December/054881.html This at least gave me a vague idea about what might be going on. Obviously, gpgsm had imported the new key into pubring.kbx, but not into pubring.gpg (note: This seems to be expected behavior as I have found out in the meantime). So I closed Thunderbird and deleted pubring.gpg for testing purposes. According to the post mentioned above, GPG then should have used pubring.kbx instead of pubring.gpg, so I expected to see the new, imported key when issuing gpg -k. But instead, gpg -k generated a new (empty) pubring.gpg instead of using pubring.kbx. 4) I have found no way to make GPG use pubring.kbx although I have double checked that I am using the most recent version of gpg4win, meaning that I am using gpg2. I also have double checked the installation directory; there is no gpg.exe, but there is gpg2.exe (and gpgv2.exe, whatever that might be). So it should use pubring.kbx, shouldn't it? 5) I have found no way to convert pubring.kbx to pubring.gpg, or to join them. To summarize: I have a .pb7 certificate with a public PGP key. I can import it to pubring.kbx. I can't import it to pubring.gpg. I can't use it because gpg4win uses pubring.gpg. I can't convert pubring.kbx to pubring.gpg. I can't join pubring.kbx with pubring.gpg. Does anybody have an idea how I could get out of this? I have access to full-blown Linux systems, so I could perform all conversions or import steps on Linux if necessary. But I still have to use the end results under Windows with the setup mentioned at the beginning of this post. Thank you very much, Binarus ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
