headers
Ben Laurie | 1 Mar 2006 14:47
Picon

Utterly Confused by Resync


I just implemented the Symmetrically Encrypted Data packet.

It also does a "resync" after the first blocksize+2 bytes. However, I
find that, unlike the MPI resync for v3 keys, as well as wiggling around
the IV I have to encrypt it.

That is, the resync operation for MPI looks like this:

1. Set the IV to the last blocksize bytes of ciphertext
2. Set the offset within the IV to zero.

Whereas for the Symmetrically Encrypted Data resync looks like:

1. Set the IV to the last blocksize bytes of ciphertext
2. Encrypt the IV
3. Set the offset within the IV to zero.

Can this possibly be right? Does the spec explain this at all?

Cheers,

Ben.

--

-- 
http://www.apache-ssl.org/ben.html           http://www.links.org/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
(Continue reading)

Permalink | Reply | 0 comments |
headers
Hal Finney | 1 Mar 2006 18:35

Re: Utterly Confused by Resync


Ben Laurie writes:
> I just implemented the Symmetrically Encrypted Data packet.
>
> It also does a "resync" after the first blocksize+2 bytes. However, I
> find that, unlike the MPI resync for v3 keys, as well as wiggling around
> the IV I have to encrypt it.
>
> That is, the resync operation for MPI looks like this:
>
> 1. Set the IV to the last blocksize bytes of ciphertext
> 2. Set the offset within the IV to zero.
>
> Whereas for the Symmetrically Encrypted Data resync looks like:
>
> 1. Set the IV to the last blocksize bytes of ciphertext
> 2. Encrypt the IV
> 3. Set the offset within the IV to zero.
>
> Can this possibly be right? Does the spec explain this at all?

The resync operation is the same for encrypted data packets as for
V3 keys.  There is a difference between the two cases, but it doesn't
involve the resync.  The difference is that V3 keys use a regular IV,
while encrypted data packets use an IV of 0 and then discard the first
blocksize+2 bytes.  But that does not affect the resync; the resync is
done exactly in the same way.

CFB works like this.  Encrypting plaintext block N starts with the
ciphertext of block N-1. Encrypt that ciphertext and then XOR the result
(Continue reading)

Permalink | Reply | 501 comments |
headers
Ben Laurie | 2 Mar 2006 12:54
Picon

Re: Utterly Confused by Resync


Hal Finney wrote:
> Ben Laurie writes:
>> I just implemented the Symmetrically Encrypted Data packet.
>>
>> It also does a "resync" after the first blocksize+2 bytes. However, I
>> find that, unlike the MPI resync for v3 keys, as well as wiggling around
>> the IV I have to encrypt it.
>>
>> That is, the resync operation for MPI looks like this:
>>
>> 1. Set the IV to the last blocksize bytes of ciphertext
>> 2. Set the offset within the IV to zero.
>>
>> Whereas for the Symmetrically Encrypted Data resync looks like:
>>
>> 1. Set the IV to the last blocksize bytes of ciphertext
>> 2. Encrypt the IV
>> 3. Set the offset within the IV to zero.
>>
>> Can this possibly be right? Does the spec explain this at all?
> 
> The resync operation is the same for encrypted data packets as for
> V3 keys.  There is a difference between the two cases, but it doesn't
> involve the resync.  The difference is that V3 keys use a regular IV,
> while encrypted data packets use an IV of 0 and then discard the first
> blocksize+2 bytes.  But that does not affect the resync; the resync is
> done exactly in the same way.
> 
> CFB works like this.  Encrypting plaintext block N starts with the
(Continue reading)

Permalink | Reply | 501 comments |
headers
Hal Finney | 11 Mar 2006 23:18

GnuPG does not detect injection of unsigned data


There has been much discussion on the net of a GnuPG bug reported by
Werner Koch on Thursday:

http://lists.gnupg.org/pipermail/gnupg-announce/2006q1/000216.html

The problem is that a sequence of OpenPGP packets, some signed and some
unsigned, was being output with the different types of data concatenated
and no indication of what part was signed and what part wasn't.
(This is my understanding from reading the report, apologies if I am
misstating it.)

Ironically I described a similar problem last month when we were talking
about packet formats for exchanging public keys.  I mentioned that I was
not sure our PGP software would always work well with arbitrary sequences
of OpenPGP packets, and that such messages raise difficult issues.
Here is what I wrote on Feb 7, replying to Ben Laurie:

> > Hmm. My implementation will eat _any_ sequence of packets.
>
> So what do you do if you decrypt a file and find a sequence of encrypted
> packets?  Or perhaps some packets signed, some encrypted, some both, all
> concatenated? Do you concatenate the results into a single output file
> (erasing the boundaries between the plaintexts, as well as information
> about what was signed and what wasn't); do you concatenate them along
> with some header information to identify where each piece starts and ends
> (which won't be reliable due to spoofing); do you output each piece to
> separate output files?  Or ask the user what he wants to do?

It appears that this was a case of exactly what I described as the first
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Shaw | 14 Mar 2006 16:58

NIST publishes new DSA draft


In the OpenPGP context, probably the most interesting bit is that the
160-bit hash limit has been removed.  The sizes supported are:

* 1024-bit key, 160-bit hash (the current DSA)
* 2048-bit key, 224-bit hash (presumably aimed at SHA-224)
* 2048-bit key, 256-bit hash (presumably aimed at SHA-256)
* 3072-bit key, 256-bit hash (presumably aimed at SHA-256)

It also adds the concept of using a larger hash than will fit by
taking the leftmost bits.

http://csrc.nist.gov/publications/drafts.html

David
Permalink | Reply | 29 comments |
headers
Hal Finney | 14 Mar 2006 20:44

Re: NIST publishes new DSA draft


David Shaw writes:
> In the OpenPGP context, probably the most interesting bit is that the
> 160-bit hash limit has been removed.  The sizes supported are:
>
> * 1024-bit key, 160-bit hash (the current DSA)
> * 2048-bit key, 224-bit hash (presumably aimed at SHA-224)
> * 2048-bit key, 256-bit hash (presumably aimed at SHA-256)
> * 3072-bit key, 256-bit hash (presumably aimed at SHA-256)
>
> It also adds the concept of using a larger hash than will fit by
> taking the leftmost bits.

The main question is whether we want to change the current draft to make
these changes.  That would probably require backing it out of "last
call" status.  Personally I think this makes sense.  There is no one
waiting urgently for this draft to be finalized AFAIK.  The alternative
will be to immediately amend the RFC with another RFC.  But for the sake
of future implementors I think it would be better to wait a few months
more and put it all into one draft.

In two places in RFC2440-bis, we mention that DSA signatures must use
a 160 bit hash.  The main one is in section 5.2.2, Version 3 Signature
Packet Format.  This is not a good location as it is not information
that is specific to V3 signature packets.  It applies to V4 signatures
as well.  This information should probably be in 5.5.2 on public key
packet formats, or at least should be repeated in 5.2.3 for V4 sigs.

It is also mentioned in section 13, Security Considerations, where we
state explicitly that RIPEMD-160 can be used, but that "DSS" as compared
(Continue reading)

Permalink | Reply | 15 comments |
headers
James Couzens | 14 Mar 2006 22:31

Re: NIST publishes new DSA draft


> We might want to think about making SHA-256 be another MUST algorithm.
> The only MUST hash now is SHA-1.  Making SHA-256 be a MUST would make
> these new key sizes be more useful, and also give us an easier fallback
> if SHA-1 should be broken.

SHA-1 was broken, last month by three Chinese cryptographers as reported 
by Bruce Schneier through is website.  On February 15, 2006 he wrote of 
a new cryptographic result, an attack faster than brute-force against 
SHA-1.  Two days later he wrote an update to his original post and a 
quote from within it:

> Earlier this week, three Chinese cryptographers showed that SHA-1 is not 
> collision-free. That is, they developed an algorithm for finding collisions
> faster than brute force.
> 
> ...
> 
> They can find collisions in SHA-1 in 2^69 calculations, about 2,000 times
> faster than brute force. Right now, that is just on the far edge of 
> feasibility with current technology. Two comparable massive computations 
> illustrate that point.

Reference URL (02/18/2006): http://tinyurl.com/4rl78
Original post (02/15/2006): http://tinyurl.com/4bmcc

With respect to your suggestion about thinking about making SHA-256 a MUST 
algorithm I couldn't agree more.

Cheers,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Hal Finney | 14 Mar 2006 23:19

Re: NIST publishes new DSA draft


Hi, James - I'm afraid you are off by a year on that.  Those reports
were from 2005, not 2006.  They have been intensively discussed here and
elsewhere in the cryptographic community.  Indeed, those findings are a
good part of why I was proposing making SHA-256 a MUST, along with the
fact that this hash will now be able to be used with DSS signatures.

Hal Finney

> > We might want to think about making SHA-256 be another MUST algorithm.
> > The only MUST hash now is SHA-1.  Making SHA-256 be a MUST would make
> > these new key sizes be more useful, and also give us an easier fallback
> > if SHA-1 should be broken.
>
> SHA-1 was broken, last month by three Chinese cryptographers as reported 
> by Bruce Schneier through is website.  On February 15, 2006 he wrote of 
> a new cryptographic result, an attack faster than brute-force against 
> SHA-1.  Two days later he wrote an update to his original post and a 
> quote from within it:
>
> > Earlier this week, three Chinese cryptographers showed that SHA-1 is not 
> > collision-free. That is, they developed an algorithm for finding collisions
> > faster than brute force.
> > 
> > ...
> > 
> > They can find collisions in SHA-1 in 2^69 calculations, about 2,000 times
> > faster than brute force. Right now, that is just on the far edge of 
> > feasibility with current technology. Two comparable massive computations 
> > illustrate that point.
(Continue reading)

Permalink | Reply | 0 comments |
headers
James Couzens | 15 Mar 2006 00:00

Re: NIST publishes new DSA draft

> Hi, James - I'm afraid you are off by a year on that.  Those reports
> were from 2005, not 2006.  They have been intensively discussed here and
> elsewhere in the cryptographic community.  Indeed, those findings are a
> good part of why I was proposing making SHA-256 a MUST, along with the
> fact that this hash will now be able to be used with DSS signatures.

My apologies, you are quite correct.  I recently joined the list a few
months ago, and haven't reviewed it historically, and as such I wasn't
present for the referenced discussion(s) intense or otherwise :-)  

I had thought it a bit strange that someone writing so comprehensively
about something related to digital signatures and to then make the
statement as you did at the end of the paragraph I quoted.  Did you have
some other intended meaning, such as broken by draft explicit
prohibition or otherwise declared deprecated in a future draft?

Cheers,

James

--

-- 
James Couzens,
Programmer
 ___ __  __  ___ 
| __|  \/  |/ __| The Electric Mail Company
| _|| |\/| | (__  Managed, Secure Email Services
|___|_|  |_|\___| http://www.electricmail.com
                  Direct Line: 604.482.1111 x152
--------------------------------------------------
PGP Key Fingerprint:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Hal Finney | 15 Mar 2006 00:31

Re: NIST publishes new DSA draft


James Couzens writes:
> I had thought it a bit strange that someone writing so comprehensively
> about something related to digital signatures and to then make the
> statement as you did at the end of the paragraph I quoted.  Did you have
> some other intended meaning, such as broken by draft explicit
> prohibition or otherwise declared deprecated in a future draft?

Yes, sorry, my language was not as precise as it might have been.
I said we should be ready in case SHA-1 were broken, but as you note
it has been officially "broken" for over a year.  However that is just
a theoretical break and no actual examples of SHA-1 message collisions
have yet been published.  So at this point SHA-1 is in a bit of a limbo
state, theoretically broken but still in widespread use.

If the attack should get worse so that SHA-1 collisions could be found
in a practical amount of time, then we would have a much more urgent
need to switch to another hash.  That is what I really meant when I
said we should be ready if SHA-1 should be broken.

Hal Finney
Permalink | Reply | 3 comments |

Gmane