--
Peter Gutmann wrote:
> Right, but it's been pure luck that that particular
> implementation (and most likely a number of others)
> happen to have implemented only a small number of hash
> algorithms that allow only absent or NULL parameters.
> Anything out there that implements a wider rang
On 9/10/06, James A. Donald <[EMAIL PROTECTED]> wrote:
Typo:
> We transmit T(k)= {W(k)} + W(k-1)|{W(k-1)} where |
> means bitwise or, curly brace means encryption.
Should read:
We transmit T(k) = {W(k)} + ((~W(k-11){W(k-1)})
where ~ means bitwise negation, | means bitwise or,
curly brace means en
--
James A. Donald:
> > Obviously we do need a standard for describing
> > structured data, and we need a standard that leads
> > to that structured data being expressed concisely
> > and compactly, but seems to me that ASN.1 is causing
> > a lot of grief.
> >
> > What is wrong with it, what a
Apparently the included cert chain didn't make it (it looks like smaller stuff
like the certs in the original message is OK, but the larger chain got
stripped by the list software). I've therefore it it online at
http://www.cs.auckland.ac.nz/~pgut001/misc/misc/misc/bad_chain.der for anyone
who wan
On 9/15/06, David Shaw <[EMAIL PROTECTED]> wrote:
GPG was not vulnerable, so no fix was issued. Incidentally, GPG does
not attempt to parse the PKCS/ASN.1 data at all. Instead, it
generates a new structure during signature verification and compares
it to the original.
*That* is the Right Way
David Shaw <[EMAIL PROTECTED]> writes:
>RFC-2440 actually gives the exact bytes to use for the ASN.1 stuff, which
>nicely cuts down on ambiguity.
Ah, OK, and it uses the NULL-parameters interpretation (section 5.2.2), which
would actually be incorrect according to the current standards but at lea
--
James A. Donald wrote:
>> Code is going wrong because ASN.1 can contain
>> complicated malicious information to cause code to go
>> wrong. If we do not have that information, or simply
>> ignore it, no problem.
Ben Laurie wrote:
> This is incorrect. The simple form of the attack is
> exac
--
Peter Gutmann wrote:
> > How does [GPG] handle the NULL vs.optional
> > parameters ambiguity?
David Shaw:
> GPG generates a new structure for each comparison, so
> just doesn't include any extra parameters on it. Any
> optional parameters on a signature would cause that
> signature to fai
--
James A. Donald
> > > We transmit T(k)= {W(k)} + W(k-1)|{W(k-1)} where |
> > > means bitwise or, curly brace means encryption.
> > Should read: We transmit T(k) = {W(k)} +
> > ((~W(k-11){W(k-1)}) where ~ means bitwise negation,
> > | means bitwise or, curly brace means encryption.
Travis
James A. Donald wrote:
> --
> James A. Donald wrote:
>>> Code is going wrong because ASN.1 can contain
>>> complicated malicious information to cause code to go
>>> wrong. If we do not have that information, or simply
>>> ignore it, no problem.
>
> Ben Laurie wrote:
>> This is incorrect. The
--
James A. Donald wrote:
> > > > Code is going wrong because ASN.1 can contain
> > > > complicated malicious information to cause code
> > > > to go wrong. If we do not have that
> > > > information, or simply ignore it, no problem.
Ben Laurie wrote:
> > > This is incorrect. The simple form
11 matches
Mail list logo
