--
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 range of
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
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 least
--
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
exactly as
--
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 fail
--
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 H. wrote:
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 simple form of
--
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
