I want to post a public key in a blog and sign the blog entry. The
problem is, that - gets converted to - -. The reader can't copy
and paste the public key, he has to remove the - first.
Example...
-BEGIN PGP PUBLIC KEY BLOCK-
public key
-END PGP PUBLIC KEY BLOCK-
-
On 5/29/12 9:15 AM, anots...@fastmail.fm wrote:
I want to post a public key in a blog and sign the blog entry. The
problem is, that - gets converted to - -. The reader can't copy
and paste the public key, he has to remove the - first.
The best solution here is to use the keyserver
On Tue, 29 May 2012 15:15, anots...@fastmail.fm said:
I want to post a public key in a blog and sign the blog entry. The
problem is, that - gets converted to - -. The reader can't copy
and paste the public key, he has to remove the - first.
If you process the signature with GPG, it
I am using gnupg via PHP's wrapper for it. I am sending an ecrypted
files to remote hosts, using two different keys for the respective
hosts. One host can decrypt the file properly, but the other host
cannot.
I am trying to troubleshoot this bug. Of course, I do not have the
private keys from the
Am Di 29.05.2012, 06:15:35 schrieb anots...@fastmail.fm:
- -END PGP PUBLIC KEY BLOCK-
Is there any way to fix this?
As Werner already said: Signing your key does not make sense. So the solution
is simple: Exclude the key out of the signed text, insert it before or
afterwards.
On 5/29/12 9:45 AM, Steven Lefevre wrote:
gpg: encrypted with 2048-bit ELG-E key, ID F1940956, created 2002-04-25
Different Public Key another_key@another_company.com
gpg: decryption failed: secret key not available
Oh, cute. A short ID collision. :) Quaero Corporation's, apparently.
On 5/29/12 11:17 AM, Hauke Laging wrote:
What can you see that from?
Can't, but it seems to be the most likely option.
The most likely cause of this seems to be --
1. His correspondent said use certificate 0xF1940956.
2. He did a gpg --recv-key 0xF1940956.
3. Quaero
Am Di 29.05.2012, 11:28:36 schrieb Robert J. Hansen:
This goes to underline the importance of proper certificate validation.
If I have the sequence of events correct, then it could have been
avoided entirely if there had been a Step 4.5, validate the certificate
he just received.
Looks like
On Tue, 29 May 2012 15:45, lefevre...@osu.edu said:
$ gpg --decrypt sensitive_file.gpg
gpg: encrypted with ELG-E key, ID F1940956
gpg: decryption failed: secret key not available
Use
gpg --keyid-format long --decrypt sensitive_file.gpg
to see the non-abbreviated key ID as stored in the
Steven,
The key who has the Short Key ID of F1940956 has the same short Key ID
as : http://keyserver.ubuntu.com:11371/pks/lookup?search=0xF1940956op=vindex
This is a flaw in the OpenPGP protocol (If I remember right). Short
Key ID are only the last 8 hexadecimal characters of the full
On 05/29/2012 11:35 AM, Werner Koch wrote:
Use
gpg --keyid-format long --decrypt sensitive_file.gpg
to see the non-abbreviated key ID as stored in the file. Use this to
find the key on a server, etc.
i've seen a lot of these mistakes where people seem to think that 32-bit
keyids are
Am Di 29.05.2012, 09:45:48 schrieb Steven Lefevre:
Beginning GPG Decryption
Using current version of GNUPG
gpg: encrypted with 2048-bit ELG-E key, ID F1940956, created 2002-04-25
Different Public Key another_key@another_company.com
gpg: decryption failed: secret key not available
Am Di 29.05.2012, 11:51:06 schrieb Daniel Kahn Gillmor:
I think switching the default to long would be on balance a Good Thing.
A smaller change which should solve most of these problems could be to
change the error message. If gpg is operating with the short format then a
respective hint
On Tuesday 29 of May 2012 17:36:25 Hauke Laging wrote:
Am Di 29.05.2012, 11:28:36 schrieb Robert J. Hansen:
This goes to underline the importance of proper certificate validation.
If I have the sequence of events correct, then it could have been
avoided entirely if there had been a Step
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 2012-05-29 17:51, Daniel Kahn Gillmor wrote:
On 05/29/2012 11:35 AM, Werner Koch wrote:
...
I think switching the default to long would be on balance a Good
Thing.
I agree, and don't see much of a reason not to use a long KeyID rather
IMHO(FWIW) it is unlikely, at best, that anyone will attack your cipher
text. haquers work by getting malware into the endpoint computers
hence it is that requiring signatures on software distributions is one
of the most critical topics on the table today
--
/MIKE
On 5/29/12 11:51 AM, Daniel Kahn Gillmor wrote:
Perhaps GnuPG should change the default of --keyid-format from short
to long?
Hurts interoperability. Once someone learns the process on PGP or
BouncyCastle or [insert OpenPGP implementation here], they're going to
want to take those same skills
On 5/29/12 11:16 AM, Tanguy Herrmann wrote:
This is a flaw in the OpenPGP protocol (If I remember right).
The protocol is fine, but it seems that the people involved did not
properly validate certificates. (Note that I'm not certain about this,
hence my seems. Maybe I should qualify it as
On Tue, 29 May 2012 18:31, r...@sixdemonbag.org said:
Honestly, this seems like something to bring up to the IETF WG. The RFC
already has a plethora of implementation recommendations: adding an
implementation recommendation of use long key IDs when possible seems
I bet that this will
On 5/29/2012 10:18 AM, Werner Koch wrote:
Hiding the keyID from the user would even be better - the mail
address should be sufficient for 99% of all users.
I use the e-mail address for almost all of my command-line work, FWIW.
--
If you're never wrong, you're not trying hard enough
Hi,
I can't remember whether I announced it, but since some weeks
keys.gnupg.net is a CNAME to pool.sks-keyservers.net
and
http-keys.gnupg.net is a CNAME to ha.pool.sks-keyservers.net
The reason for this change is that it is useless to spend a lot of work
in maintaining such a second
On 5/29/12 1:18 PM, Werner Koch wrote:
Frontends should handle this problem.
The problem is that most people developing front ends are making them
pretty darn user-hostile.
A few years ago while taking some HCI courses, I did a usability study
on the most common certificate interface -- the
On May 29, 2012, at 11:51 AM, Daniel Kahn Gillmor wrote:
On 05/29/2012 11:35 AM, Werner Koch wrote:
Use
gpg --keyid-format long --decrypt sensitive_file.gpg
to see the non-abbreviated key ID as stored in the file. Use this to
find the key on a server, etc.
i've seen a lot of these
On May 29, 2012, at 1:18 PM, Werner Koch wrote:
On Tue, 29 May 2012 18:31, r...@sixdemonbag.org said:
Honestly, this seems like something to bring up to the IETF WG. The RFC
already has a plethora of implementation recommendations: adding an
implementation recommendation of use long key
On Tue, May 29, 2012 at 1:47 PM, David Shaw ds...@jabberwocky.com wrote:
On May 29, 2012, at 11:51 AM, Daniel Kahn Gillmor wrote:
What is your concern here, though - accidental or intentional collision?
Certainly both; while accidental collision isn't probable, 32-bit IDs
aren't exactly
On May 29, 2012, at 2:05 PM, Sam Whited wrote:
On Tue, May 29, 2012 at 1:47 PM, David Shaw ds...@jabberwocky.com wrote:
On May 29, 2012, at 11:51 AM, Daniel Kahn Gillmor wrote:
What is your concern here, though - accidental or intentional collision?
Certainly both; while accidental
On 5/29/12 1:54 PM, Steven Lefevre wrote:
This is, not surprisingly, the case. There was bad logic in my script
and somehow, somewhere, it's using the wrong key for this particular
host.
The good news is it's an easy problem to fix. :)
Get in touch with your contact over there (preferably
On Tue, May 29, 2012 at 11:28 AM, Robert J. Hansen r...@sixdemonbag.org wrote:
1. His correspondent said use certificate 0xF1940956.
2. He did a gpg --recv-key 0xF1940956.
3. Quaero Corporation already has a certificate with the
short ID of 0xF1940956 on
On Tue, 29 May 2012 19:44, r...@sixdemonbag.org said:
Anyway. If people are interested in what I found out about effective
user-interface design with respect to certificate managers, say the
word. Otherwise I'll crawl back under my rock and leave the subject
GPA has many different ways to
On Tue, 29 May 2012 19:54, lefevre...@osu.edu said:
This is, not surprisingly, the case. There was bad logic in my script
and somehow, somewhere, it's using the wrong key for this particular
Speaking of scripts: Scripts should use --with-colons and never try to
parse the regular output.
On Tue, May 29, 2012 at 3:29 PM, Werner Koch w...@gnupg.org wrote:
On Tue, 29 May 2012 19:54, lefevre...@osu.edu said:
This is, not surprisingly, the case. There was bad logic in my script
and somehow, somewhere, it's using the wrong key for this particular
Speaking of scripts: Scripts
On 05/29/2012 02:18 PM, David Shaw wrote:
The reason I bring it up is that using the v3 key attack, 64-bit key IDs have
no particular benefit over 32-bit IDs for intentional collisions (i.e. an
attacker generating a key with the same key ID as the victim in order to
confuse matters and/or
Am Di 29.05.2012, 21:29:51 schrieb Werner Koch:
I have said this at least a hundred times, but it is still not known
well enough.
You probably mean: Among the readers of this list. How much known may it be
in the wild...?
Would an option --annotate which enables
--with-colons, --batch,
On 5/29/12 3:23 PM, Werner Koch wrote:
However, changing such a common UI might result in a
lot of negative comments - people love what they once learned.
Absolutely. The good news, though, is that (at least in the Free
Software world) the 'market' is fragmented. No one particular key
manager
On May 29, 2012, at 3:34 PM, Daniel Kahn Gillmor wrote:
On 05/29/2012 02:18 PM, David Shaw wrote:
The reason I bring it up is that using the v3 key attack, 64-bit key IDs
have no particular benefit over 32-bit IDs for intentional collisions (i.e.
an attacker generating a key with the same
On Tue, 29 May 2012 22:02, mailinglis...@hauke-laging.de said:
You are probably running gpg non-interactively. In order not to break
scripts
it is strongly encouraged to use scripted output of gpg only with the options
--with-colons, --batch and --status-fd. See http://www.gnupg.org/...;
On Tue, 29 May 2012, Robert J. Hansen wrote:
. . .
Tabular data is the Right Thing To Do in two major use cases.
The first is when you have a noninteractive display of identical
field(s) for multiple pieces of data. Consider a printed almanac: if it
wants to convey a list of countries and
On 5/29/12 9:57 PM, reynt0 wrote:
In general, being able to examine variation of content within
uniformity of structure is also a way to legitimate the
specific content of interest.
As I said, it's useful when data must be contextualized. For a
spreadsheet, the information in one row must be
38 matches
Mail list logo
