On Jun 21, 8:57 pm, "Brian Smith" wrote:
> From arcfour.c:
>
> http://mxr.mozilla.org/mozilla/source/security/nss/lib/freebl/arcfour...
>
> My guess is that valgrind is considering malloc(5) to allocate 5 bytes, when
> really it allocates 8 bytes at least (because of alignment).
Strictly speaking
On Jun 22, 7:10 pm, Mads Kiilerich wrote:
> Wouldn't the bulk word processing (sic!) that really matters
> perform even better if it didn't have to consider masks because leading
> and trailing bytes had been handled byte by byte?
That is already done. There is separate code for the leading, bul
Nelson Bolyard wrote, On 06/22/2010 07:49 AM:
On 2010-06-21 17:57 PDT, Brian Smith wrote:
From arcfour.c:
http://mxr.mozilla.org/mozilla/source/security/nss/lib/freebl/arcfour.c#390
My guess is that valgrind is considering malloc(5) to allocate 5 bytes, when
really it allocates 8 bytes at
On Jun 22, 1:49 am, Nelson Bolyard
wrote:
> I presume that there must be some incantation that one can give to valgrind
> that will force it to shut up about arcfour.
You can write a valgrind suppression, which is essentially a stack
trace pattern that will cause matching errors to be ignored:
h
On 2010-06-21 17:57 PDT, Brian Smith wrote:
> From arcfour.c:
>
> http://mxr.mozilla.org/mozilla/source/security/nss/lib/freebl/arcfour.c#390
>
> My guess is that valgrind is considering malloc(5) to allocate 5 bytes,
> when really it allocates 8 bytes at least (because of alignment).
See the exp
>
> Yes, it works correctly, so I assume that it doesn't use the extra
> bytes. It is however not just reading uninitialized memory (which
> valgrind usually tracks correctly), but it reads unallocated memory.
> It is also interesting that it doesn't read beyond the bounds for
> small sizes, so
On 2010-06-22 07:06 PDT, Konstantin Andreev wrote:
> At the moment, NSS softoken still return CKR_DATA_LEN_RANGE when CBC/ECB
> ciphers are updated with odd length.
>
> I wonder, are any chances for this aspect of NSS softoken to be more
> PKCS#11 compliant in the near future ?
Yes.
Step 1. Fi
On 2010-06-22 06:24 PDT, Logan Jones wrote:
> Whenever someone receives an email with a .p7m extension as an
> attachment, Thunderbird eats it.
I suppose you mean /attachment/ rather than /extension/.
> Normally it would be saved to the desktop and decrypted with the
> standalone entrust applica
Long time ago, on the end of 2002, in the "Cryptoki" mail list at RSA Lab, in
the thread
"Do unpadded block ciphers allow odd length updates?", started on 20 Dec
2002 by Nelson Bolyard,
it was discussed how C_EncryptUpdate should behave when passed with odd input
length (not multiple of ci
Whenever someone receives an email with a .p7m extension as an
attachment, Thunderbird eats it. Normally it would be saved to the
desktop and decrypted with the standalone entrust application, but we
can't even get that far. If I view the message source, I can see that
it's supposed to be there, bu
On 2010-06-21 17:57 PDT, Brian Smith wrote:
> From arcfour.c:
>
> http://mxr.mozilla.org/mozilla/source/security/nss/lib/freebl/arcfour.c#390
>
> My guess is that valgrind is considering malloc(5) to allocate 5 bytes, when
> really it allocates 8 bytes at least (because of alignment).
I presume
11 matches
Mail list logo
