Le 2017-10-31 à 13:01, Peter Lebbing a écrit :
> Revocations are done by the primary key. If the user has lost the secret
> primary, they should fetch their revocation certificate, not fool around with
> the subkeys ;-). (Incidentally, this is why you don't need revocation
> certificates for indivi
Le 2017-10-31 à 12:48, Peter Lebbing a écrit :
> Having read my follow-up, do you now agree? If the subkey is revoked as
> "compromised", all is well and good?
I can't see any reason why this should be problematic. And for
signatures that you know for sure are pre-ROCA, it makes sense to keep
the
Le 2017-10-31 à 12:39, Peter Lebbing a écrit :
> To clarify, do you agree if I reword the paragraph you contest as:
>
> But, I agree that the reverse is not true: a compromised subkey does not
> compromise the primary key in any way I can think of. And systems
> checking for ROCA should not reject
2017-10-30 23:44 GMT+10:30 Peter Lebbing :
> But, I agree that the reverse is not true: a compromised subkey does not
> compromise the primary key in any way I can think of. And systems
> checking for ROCA should not reject a certificate because there is
> something wrong with an already revoked k
Le 2017-02-19 à 01:45, Peter Lebbing a écrit :
> It failed on a trivial point: by the Friday before the congress, I had only
> received four signups. A list with five keys is a poor list indeed. I switched
> the model to the classic "bring keyslips" model.
Ah, fair enough. That's a bit unfortunat
Hello,
Le 2016-12-05 à 00:03, Peter Lebbing a écrit :
> I am asking for your thoughts on a variant of the organization of the
> keysigning party. I'll explain my reasoning and intentions, and I would
> like to know if you think I forgot to think of something important. Is
> there a way a malicious
Le 2017-01-18 à 22:48, Miroslav Rovis a écrit :
> On 170115-22:17+0100, Juan Miguel Navarro Martínez wrote:
> ...
>> Lastly, revoke the old one if you aren't going to use it publicly anymore.
> Isn't is wrong to revoke a key which you don't consider was compromised?
> If you don't want to use it, i
Le 2016-12-14 à 04:34, Peter Lebbing a écrit :
> Oh, not at all, I hadn't even noticed one could see it that way.
My bad; such is the life of the email-user.
> Or hang a truly huge printout on the wall and at the start of the
> session, together observe that it is correct. Any latecomers can be t
Le 2016-12-12 à 03:45, Peter Lebbing a écrit :
> My e-mail was 1424 words though, so I am afraid I ended up in your
> wishful thinking area.
>
> The remaining 1607 words are in the sections "Background" and "Option
> for advanced users", and those words happen to include the name Lachlan.
> Go che
Le 2016-12-12 à 03:45, Peter Lebbing a écrit :
> I really like this suggestion! I had to think about it for a while
> before I could see a way to make it work. The trouble is that I want
> caff to be able to process the file, and for that I need to keep it
> having much of the same patterns. I ende
Le 2016-12-08 à 22:30, Stephan Beck a écrit :
> Yes, to your first question. How you would do that via the
> hash-on-the-projector method, is not clear to me, though. Would that be
> for generating the (initial) list of the organizers as in Sassaman
> Efficient (as an additional service for people
Le 2016-12-09 à 00:25, Peter Lebbing a écrit :
> Yes, the late attendees definitely need to be there at the beginning of the
> party, verifying that the SHA256 checksum printed at the top of their scrubbed
> list is the one being read aloud and hearing everybody confirm their
> fingerprint
> is co
Le 2016-12-08 à 22:05, Peter Lebbing a écrit :
> Stephan and Lachlan, thank you for thinking about this! I need to make a
> decision soon, I really need feedback!
Not a problem, efficient keysigning is something I've been pondering for
a while, so I'm really glad to see people working in the area.
Le 2016-12-08 à 08:14, Stephan Beck a écrit :
> Doesn't your proposal imply that late attendees could
> make their way through all the keysigning without fingerprint
> verification? Or do I miss something?
If I understand correctly, the late attendees still get a copy of the
fingerprints after the
Le 18 août 2016 00:09, "Andrew Gallagher" a écrit :
> Parcimonie already exists. But it's an optional extra that most people
> don't install (or even know of). People shouldn't be expected to
> install or configure extras before they have a (safely) usable system.
I coincidentally am working on a
Le 2016-08-02 à 23:35, MFPA a écrit :
> But to bring it back
> on-topic, would a DKIM signature on such a message be for the
> gmail.com domain or the twopif.net domain?
It the key is from twopif.net, though obviously Google have the private
key rather than myself.
> Is this a Denial of Service a
> Does that mean you sent the email from the @gmail.com address, but
> because you happened to be logged in with the @twopif.net address
> Google took it upon themselves to change the from address? I wouldn't
> like that: it is not up to the email provider to choose which of my
> email addresses I
hasn't misissued a signature, an
attacker needs to at least compromise each domain separately.
2. With Gmail at least, the From seems to be replaced with the account
that I log in from, yielding the following (lach...@twopif.net is a
Google Apps address):
From: Lachlan Gunn
X-Google
Hello,
Has anyone had a go at using DKIM signatures as a way of verifying
control of an email address with GPG?
I've seen a few mentions of the idea online, particularly here:
https://security.stackexchange.com/questions/107417/pgp-key-signing-robot-dkim-verified-emails/
https://github.com/
Le 2016-07-27 à 20:47, Samir Nassar a écrit :
> Should it be understood that GnuPG Modern is similar to a development
> branch?
It's more stable than that, WK's words from a few months ago were "it is
not just stable, but modern! Go and use it."
If it's any indication, gnupg2 in Debian testing i
> Well, there's a little bit of a chicken-and-the-egg problem here. If
> new projects are told "don't evangelize here", how will they let users
> who might be interested in their project know it exists? Evangelization
> is important. I don't think we want to adopt a no-evangelization rule,
> but
>> - would anybody else like to suggest improvements to the workflow?
One thing that I forgot to mention is that it would be good to have some
way to copy master keys to new media or to rewrite them to existing
ones. This could be prompted if some but not all disks have master keys
for example.
> There has been some discussion on debian-devel[1] about making a
> bootable Debian Live CD specifically for GnuPG
I have thought for a while that something like this would be a good
idea, it's been sitting on the list of things to have a go at for a
while, so I'm glad to see that someone is actu
Hello,
Apologies if this is an excessively newbie question, but is there any
reasonably automated way to do verification via the web-of-trust when
you don't have all the intermediate steps in the keyring already?
All the pathfinders I've seen have been full-on HTML websites, is there
anything out
Le 2016-02-03 21:12, Robert J. Hansen a écrit :
> Time for my semi-regular FAQ perusing and updating. I plan on updating
> the FAQ to include a link to the FSF's email security guide, but that
> seems like such an unobjectionable change I'm not going to kick it
> around the list for pre-approval.
> It's interesting you're using "biometric" as a qualifier implying something
> "good". I wouldn't agree.
I mean in the sense that it's a lot easier for someone doing MITM to
transparently rewrite the signatures in an email than it is to
transparently detect that you are reading the verification c
> I haven't looked at the links yet, but what is your purpose? Do you want
> to detect rogue keyservers in the keyserver network, or perhaps attacks
> on keyservers?
Essentially I'm looking to see if it's possible to make a secure
directory service, for some definition of secure, even against
pers
Hello,
Sorry to bring this thread back from the dead, but now that I have a
preprint out I can elaborate a bit more on my motivations for this
previous discussion.
I've spent a little bit of time investigating the use of Tor to create
an interactive protocol for auditing keyservers, the idea bein
By a weird freak of coincidence I am currently writing some code to
simulate this type of experiment.
It doesn't break relativity, rather (roughly speaking) it shows that
quantum measurements cannot be predetermined unless you have FTL or some
kind of non-local theory that predetermines the random
I'm about to start writing some documentation in Docbook, so I can report
back after that's done if you like.
Thanks,
Lachlan
Le 6 févr. 2016 13:12, "Robert J. Hansen" a écrit :
> Since I seem to have become the doyen of documentation, I figure I
> should ask: what markup language and/or output
>
> I don't understand, what are the session keys encrypted with? I thought
> they
> were encrypted to the original smartcard subkey, which is dead. With two
> smartcards, you might be able to get by if you get all your correspondents
> to
> use the new subkey before the second smartcard dies. It s
>
> I'd say that's a bad idea anyway. What if the smartcard breaks?
>
Then you rotate to the new key with little or no data loss because all of
the session keys are logged. You can generate the key on-chip so that it
is unable to ever leave the smartcard, which is obviously desirable from a
secur
> Not that I'm aware of.
Ok, thanks, might make an interesting project then if I get some more free
time.
> Without any rigorous thought having yet gone into it, it seems they have
the same /effective/ properties.
The first reason is that you can't do it if the key only exists on a smart
card.
Sure, but you have to bootstrap somehow. TOFU doesn't come into play until
after you've received a response anyway, so unless you can find the key
through some out-of-band source, then for the initial contact you have to
choose between either making an educated guess as to what the key is, or
send
Le 14 janv. 2016 17:30, "Robert J. Hansen" a écrit :
> Fingerprint verification. An attacker can create a fraudulent
> certificate, but an attacker cannot (to the best of our knowledge)
> create a certificate that has an identical fingerprint to the real one.
Yes, of course. I'm just wondering
Hello,
Through my searches online and looking at g10/getkey.c, it seems that when
multiple keys exist with the same name/email/etc., gpg will use the first
one that it finds in the database. Is this correct?
If so, suppose an attacker inserted a fake key with my details into an HKP
keyserver. W
>
>
>> You've already received good answers on your questions, so some questions
> for you. :) What is your concern about signing the key? And are you aware
> that local signatures will not be communicated beyond your keyring?
I actually ran into this issue the other day. For me it's problemati
Hello,
According to the documentation that I've found, it is called "passwords and
keys".
Thanks,
Lachlan
Le 27 déc. 2015 10:45, "Rob Landau" a écrit :
> Good day, I have just received my first Linux system (Ubuntu 14.04) It
> has Seahorse installed, but I don't see any GnuPG application. Ho
I'm a big fan of that list, and for some time I've been meaning to generate
a tweaked version that uses binary numbering, having recently needed to
generate a passphrase without a dice to hand. Using a coin and rejection
sampling isn't too hard, but it's rather annoying to have to throw away 20%
of
Long story short, there exist algorithms that are hypothesised tho be
QC-resistant, though as far as I know nothing is proven in that
respect. Those that do exist, there's still a substantial possibility
that they'll be broken. Key and signature sizes are generally large,
kilobytes to megabytes.
Hello,
Is there any way make GNUPG or libgpgme generate a signature from an
externally-computed hash? My justifications for this are twofold:
1. Isolation---by removing the need for gpg to see the original data, it
becomes possible to perform signatures on a system that is completely
isolated, a
41 matches
Mail list logo
