On Thu, 2 May 2013 06:48, r...@sixdemonbag.org said:
thinking of these problems, and if-and-when Werner and g10 Code decide
to shift the default behaviors I'm certain it will be towards a stronger
hash algorithm.
We always tried to make sure that new algorithms are deployed for a long
time
On 04/28/2013 04:26 AM, Robert J. Hansen wrote:
On 4/27/2013 8:01 PM, Daniel Kahn Gillmor wrote:
I don't think this recommendation was made to defend against preimage
attacks. Avoiding the use of SHA-1 in certifications in general is a
step towards defend against collision attacks, which is
On 5/1/2013 10:16 PM, Daniel Kahn Gillmor wrote:
It doesn't facilitate a collision attack against that specific
certification; but if a collision attack is possible against a
particular digest, then *any* signature made over that digest becomes
suspect.
First, thank you for a thorough reply.
On 05/02/2013 12:03 AM, Robert J. Hansen wrote:
Eve manages to inject data into your collection that makes the
data collection have the same digest as a particularly weird User ID
when bound to your primary key (i'm handwaving past the details of the
OpenPGP boilerplate involved in a self-sig
On 5/2/2013 12:33 AM, Daniel Kahn Gillmor wrote:
if it was a preimage attack (even for SHA1), then yeah, it'd be game
over in a lot of horrible ways i don't want to think about in detail
right now :)
I think I can make a compelling argument this is a preimage attack and
not a collision attack,
On 5/2/2013 12:48 AM, Robert J. Hansen wrote:
She cares what the collision is: it has to be a valid OpenPGP signature
sequence.
Erf, did I really write that?
s/signature/User ID
The point being the User ID isn't allowed to be completely arbitrary:
there's a lot of structure to it. I think
On 05/02/2013 12:51 AM, Robert J. Hansen wrote:
On 5/2/2013 12:48 AM, Robert J. Hansen wrote:
She cares what the collision is: it has to be a valid OpenPGP signature
sequence.
Erf, did I really write that?
s/signature/User ID
The point being the User ID isn't allowed to be completely
On 4/27/2013 8:01 PM, Daniel Kahn Gillmor wrote:
I don't think this recommendation was made to defend against preimage
attacks. Avoiding the use of SHA-1 in certifications in general is a
step towards defend against collision attacks, which is territory that
SHA-1 is heading into. (i agree
On 04/26/2013 11:47 AM, Robert J. Hansen wrote:
For my own lookout, I don't see that this practice would give me very
much. If SHA-1 falls victim to preimage attacks
I don't think this recommendation was made to defend against preimage
attacks. Avoiding the use of SHA-1 in certifications in
On 4/26/2013 5:47 AM, Robert J. Hansen wrote:
For my own lookout, I don't see that this practice would give me very
much. If SHA-1 falls victim to preimage attacks then I'm completely
screwed anyway on a few dozen fronts simultaneously, and my certificate
is the least of my worries.
If I
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Thu, Apr 25, 2013 at 11:47:49PM -0400, Robert J. Hansen wrote:
A preimage attack on SHA-1 is my house being on fire: avoiding SHA-1 for
self-signatures is making sure to turn off the coffeepot.
While I agree with what you're saying, the big
On Apr 26, 2013, at 12:18 PM, Mason Loring Bliss ma...@blisses.org wrote:
On Thu, Apr 25, 2013 at 11:47:49PM -0400, Robert J. Hansen wrote:
A preimage attack on SHA-1 is my house being on fire: avoiding SHA-1 for
self-signatures is making sure to turn off the coffeepot.
While I agree with
On 26/04/13 03:13, Mason Loring Bliss wrote:
gpg --export-options export-minimal --export keyid | gpg --list-packets |
grep 'pref-hash-algos'
...I see algorithm 2 still there.
I think you're mixing things up. pref-hash-algos is the algorithms you'll
accept from others.
The page you linked
On 4/26/2013 12:18 PM, Mason Loring Bliss wrote:
While I agree with what you're saying, the big difference between this
situation and your example is that it's trivially easy for me to say use
this digest method instead of this other one and then forget about it.
Sure: but what does it gain
14 matches
Mail list logo
