Re: Your Thoughts
Alyssa Ross writes: >> > For example, why isn't ask-cert-level a default? >> >> For an alternative view on ask-cert-level see also: >> >> https://debian-administration.org/users/dkg/weblog/98 > > Oh, interesting. Thank you for showing this to me. I had it in my head > that a "weak" signature would count as a marginal in the web of trust, > but I suppose I was wrong about that. > > In that case, I agree that ask-cert-level doesn't make sense as a > default. Well, that's also an ecosystem issue, and if I'm not mistaken this thread (or was it another one?) was going quite far in the “let's fix the ecosystem and keep the standard” direction. “weak” *could* be used for verification. For instance, if I were to write an OpenPGP client, I'd likely make it so that: * Trust (which is 0-255 in the standard) is a slider with marks like “I trust not at all|a bit|a lot| completely” (with a proper sentence so that people understand, not like what I'm putting here) * Signature level (4 levels in the standard) is a similar slider * Both trust and signature level are mapped to a [0, 1] value, and multiplied to get the amount of confidence we have thanks to this particular signature that the key is correct * All such amounts of confidence get added, and the “3-marginals or 1-full” rule becomes a simple number that needs to be passed with this addition (also configured as a slider with some “normal user / … / paranoïd user” landmarks) (for trust signatures, in such a scheme they'd first be cut off to follow the OpenPGP certification, and then get multiplied by the length of the path, to account for decreasing trust along longer paths) This is compatible with RFC4880 (well, except it doesn't respect the “SHOULD” that full trust is 120 and marginal 60, because it actually uses the whole range). So ask-cert-level might make sense as a default. Just not as GnuPG's default, as GnuPG doesn't have such a behavior (and no client that I know of currently do). But someday, maybe. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: SKS Keyserver Network Under Attack
Mirimir via Gnupg-users writes: >>- Embeds a hardcoded list of already-disrupted keys for which packets >> should be filtered-out when serving them > > That's what I meant. Plus some mechanism for testing keys, so poisoned > ones are blocked, as soon as possible. > > It'd also be useful for SKS to report "this key has been poisoned", and > suggest alternative sources, rather than just failing silently. I think we can't rely on humans actually reading the output, even if GnuPG was able to display the output on eg. `--refresh-keys` in a way understandable by a human. Also, the aim of my suggestion was to actually *not* block the keys. This second point of part 1 is there to just filter some hardcoded list of packets, thus making key updates still propagate. The first point was there to prevent additional keys from being poisoned, and the second to limit the damage caused by already-existing keys -- the first one is unfortunately quite necessary, as sks-keyservers can't reasonably be coordinating changes on the ~220 keyservers every time a new key gets poisoned (or even twice, for that matter, one flag day is already bad enough) >> Do you think such a plan might be reasonably done, to at least keep the >> most basic functionality of not breaking existing installations and >> allow them to keep revocations flowing? The biggest issue I can see is >> it requires a quite big amount of development work. > > But less work than actually fixing SKS, right? Well, nowadays “fixing SKS” means “making hagrid able to synchronize its cryptographic-only content and propagate third-party signatures under some circumstances”, as far as I understand. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: SKS Keyserver Network Under Attack
> 1. We would have to ensure that all keyservers block the same > uploads. One permissive keyserver is a backdoor into the entire > system. We can’t block bad keys at reconciliation time for the same > reasons that have been hashed to death already. One way to do that, though it would mean officially sunsetting SKS, might be to: 1. Publish an update to SKS that: - Blocks all uploads of any packet that is not a revocation signature packet (maybe also having to check the revocation is actually correctly signed, to avoid flooding of revocation packets to become the new flaw) - Embeds a hardcoded list of already-disrupted keys for which packets should be filtered-out when serving them 2. Pressure keyserver operators into updating 3. Kick all not-up-to-date keyservers from the pool after some delay deemed acceptable (shorter means less broken GnuPG, longer means less keyservers kicked out) Note: I do not know how the pool is handled. Maybe this would mean that the new update to SKS would need to stop synchronizing with earlier versions, and that the hkps pool should be turned off until enough keyservers are updated to handle the load? Do you think such a plan might be reasonably done, to at least keep the most basic functionality of not breaking existing installations and allow them to keep revocations flowing? The biggest issue I can see is it requires a quite big amount of development work. Hope that helps, Leo ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: [NIIBE Yutaka] STM32F103 flash ROM read-out service
On 06/06/2018 06:56 PM, NdK wrote: > Il 06/06/2018 17:49, Tom Li via Gnuk-users ha scritto: > >> BTW, BasicCard and JavaCard seemed even more obscure and I cannot find >> any public service of cracking. > Because those are (at least should be) based on secure chips. > >> But it does not solve any real problem in the perspective of cryptography. >> They are all "security through obscurity" at best, just driving out script >> kiddies (or equipment kiddies?) at worst. > The only secure (even against decapping attacks) device I know of is a > very old parallel-port "key" a friend described me ~25y ago. > It was made of 3 silicon layers: the outer ones only contained interface > circuits and 'randomness' while the keys and the logic were in the > central layer. Trying to remove the outer layers destroyed the random > patterns that were used as 'internal master key', rendering the rest > completely useless. Some people do reverse-engineering based on photons emitted by transistors switching. These would get through this shielding. Unfortunately, I can't find again the link to the conference talk where I heard people explaining they did that… sorry. Another kind of attack would be EM pulses / lasers for error-ing a crypto computation, that would get through this shielding too. There are defenses against these attacks (well, for the transistors-emitting-photons attack I'm not really sure), that are deployed in secure elements. Attacks like this are tested by CC/EAL evaluation laboratories. All that to say: hardware security, to me, is a way to increase the cost of the attacker to perform an attack. All devices are eventually vulnerable, given the right price, the point is to make attack more costly than the benefit from breaking the card and/or than finding a way around the card. (I'm not going to extend this point to software security, but I'd think it most likely holds there too) Oh, and also to say: choosing between a non-secure-element open-source token and a secure-element NDA-ed-and-thus-non-open-source token is not an obvious choice. HTH, Leo ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Breaking changes
On 05/22/2018 11:48 PM, Dennis Clarke wrote: > On 05/22/2018 05:38 PM, Dan Kegel wrote: >> Lessee... >> https://en.wikipedia.org/wiki/GNU_Privacy_Guard >> already give an end-of-life date for 2.0, but none for 1.4. >> And since Ubuntu 16.04 includes 1.4, there are likely >> to still be a few vocal 1.4 users out there. >> >> How about announcing an end-of-life date for 1.4 that >> is in the future (say, by 3 to 6 months)? > > Too fast. Think 12 months as a minimum. There is prod code > out there running for years and a timeline that allows proper > project schedule/costing/testing would be better. If the announced end-of-life is 12 months, then people will complain for 9 months, and maybe start working on migrating during the last 3 months. I mean, I'm still seeing people actively developing python2 code bases without even thinking of migrating to python3 *now*, and retirement was initially announced for 2015… The longer you leave people with maintenance, the longer they will want maintenance past the deadline. I think 3-6 months is more than enough, and if people can't manage to update their production code in this time frame they can live with an un-maintained GnuPG until they finish migrating (unless they want to pay for paid support for continued 1.4 maintenance, that is). I don't have a personal opinion, but dropping 1.4 appears to have two advantages to me: first, it reduces the voluntary maintenance burden, and second, it may help gather funding for work on 2.3, if people choose to contract with g10code for continued maintenance. GunPG 1.4 has been out for way longer than necessary, and people are never going to migrate out of it unless they are forced to. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Efail or OpenPGP is safer than S/MIME
On 05/14/2018 09:45 AM, Werner Koch wrote:> The topic of that paper is that HTML is used as a back channel to create > an oracle for modified encrypted mails. It is long known that HTML > mails and in particular external links like > are evil if the MUA actually honors them (which many meanwhile seem to > do again; see all these newsletters). Due to broken MIME parsers a > bunch of MUAs seem to concatenate decrypted HTML mime parts which makes > it easy to plant such HTML snippets. The full details appear to be out [1]. If I read it correctly, it also has another attack, no longer based on user agents concatenating HTML mime parts, but also based on CFB gadgets. Which, here, looks like a flaw in the OpenPGP specification indeed (and thus GnuPG's implementation of it), and not in MUAs? [1] https://efail.de/ ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
