PKCS#7 has been superseded by the IETF's Cryptographic Message Syntax, CMS.
You should check within the S/MIME working group for updates.
William
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Alex Alten
Sent: Saturday, October 07, 2006 12:29 AM
I've been notified that we had a paper accepted for the cryptographers'
track. If you're concerned about that track, you could try contacting
Masayuki Abe, the PC Chair, directly. If you're interested in other
tracks I'm not sure what to suggest.
William
-Original Message-
From: [EMAIL
Anyway, the attack applies even if you throw away the
ASN.1 data.
If you ignore the ASN.1 data you expect the hash to be
in a fixed byte position, so the attack does not apply.
It's correct that the attack doesn't apply if you expect
the hash to be in a fixed byte position. I would say
This is incorrect. The simple form of the attack
is exactly as described above - implementations
ignore extraneous data after the hash. This
extraneous data is _not_ part of the ASN.1 data.
James A. Donald wrote:
But it is only extraneous because ASN.1 *says* it is
RFC-2440 actually gives the exact bytes to use for the
ASN.1 stuff, which nicely cuts down on ambiguity.
This amounts to *not* using ASN.1 - treating the ASN.1
data as mere arbitrary padding bits, devoid of
information content.
Again, not quite right. You have to do a memcmp() and
make
If so, I fear we are learning the wrong lesson, which
while valid in other contexts is not pertinent here.
TLS must be flexible enough to accommodate new
algorithms, this means that the data structures being
exchanged are malleable, and that implementations must
validate strict
Adi Shamir and Nicko Van Someren, Playing Hide and Seek with Stored Keys:
http://citeseer.ist.psu.edu/vansomeren98playing.html
Shamir, not Rivest. Easy mistake...
William
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Douglas
F. Calvert
Sent:
Useful references are
http://cr.yp.to/antiforgery/cachetiming-20050414.pdf -- the Bernstein paper
www.wisdom.weizmann.ac.il/~tromer/papers/cache.pdf - related work by
Eran Tromer.
William
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Travis H.
Good, bad, right, wrong, correct, incorrect, meaningful, meaningless... Who
knows? Don't ask us. We are simply trying to contribute something new that
we strongly believe in
Right. But can you explain *why* you strongly believe in it?
William
Isn't what you are referring to called secure number of rounds? In other
words the number of rounds after which no known attack exists that can break
the cipher faster than brute-forcing the key?
It looks like I have no choice but to invent a new term, PRF rounds - the
number of rounds
Don't forget Bleichenbacher's error channel attack on SSL
implementations, which focussed on the mac then encrypt design of
SSL... web servers gave different error for malformed padding vs
plaintext MAC failure. The lesson I drew from that is the
conservative choice is encrypt then MAC.
From what I understand simple quantum computers can easily
brute-force attack RSA keys or other types of PK keys. Is
ECC at risk too? And are we at risk in 10, 20 or 30 years from now?
Quantum computers break RSA, cryptosystems based on discrete log
over finite fields, and cryptosystems
On 12/14/05, Peter Gutmann [EMAIL PROTECTED] wrote:
I don't know if there's any site tracking this, but (as the
tutorial says) you
can either go with PKCS #1 (the de facto standard, easy to
implement and
widely used) ...
Actually, I'm embarassed to admit this but I've seen PKCS
In Peter Gutmann's godzilla cryptography tutorial, he has some really
good (though terse) advice on subtle gotchas in using DH/RSA/Elgamal.
I learned a few no-nos, such as not sending the same message to 3
seperate users in RSA (if using 3 as an encryption exponent).
My question is, what
NIST, in its series of FIPS standards and Special Publications, has defined
federal standards for digital signatures and modes of operation for symmetric
ciphers, and is moving towards standardizing key exchange mechanisms based
on public key algorithms. Those standards are also free, though
Don't ever encrypt the same message twice that way, or you're likely to
fall to a common modulus attack, I believe.
Looks like it (common modulus attack involves same n,
different (e,d) pairs).
However, you're likely to be picking a random symmetric key as the
message, and Schneier
A similar approach enabled Bleichenbacher's SSL attack on
RSA with PKCS#1 padding. This sounds very dangerous to me.
William
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of cyphrpunk
Sent: Friday, October 28, 2005 5:07 AM
To: [EMAIL PROTECTED];
To: cryptography@metzdowd.com
Subject: RE: ECC patents?
--
Whyte, William [EMAIL PROTECTED]
$25MM figure:
http://lists.jammed.com/ISN/2003/10/0097.html
I stand corrected.
However as was pointed out previously:
: : Further, the license would be limited to only
: : prime
http://www1.ietf.org/proceedings_new/04nov/slides/saag-2/sld9.htm:
What is Really Covered
o The use of elliptic curves defined over GF(p) where p is a prime
number greater than 2^255 when the product satisfies the Field of
Use conditions
o Both compressed and
They paid $25MM.
William
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of James A. Donald
Sent: Thursday, September 15, 2005 12:54 PM
To: cryptography@metzdowd.com
Subject: RE: ECC patents?
--
Whyte, William:
It hints that only some
] On Behalf Of James A. Donald
Sent: Thursday, September 15, 2005 12:54 PM
To: cryptography@metzdowd.com
Subject: RE: ECC patents?
--
Whyte, William:
It hints that only some particular curves have been
licensed. It could be that NSA has decided not to buy
a license for the other
I haven't read the original paper, and I have a great deal of
respect for Markus Jakobsson. However, techniques that establish
that the parties share a weak secret without leaking that secret
have been around for years -- Bellovin and Merritt's DH-EKE,
David Jablon's SPEKE. And they don't require
http://theory.csail.mit.edu/~yiqun/shanote.pdf
No real details, just collisions for 80 round SHA-0 (which I
just confirmed)
and 58 round SHA-1 (which I haven't bothered with), plus the
now famous work
factor estimate of 2^69 for full SHA-1.
As usual, Technical details will be
R.A. Hettinga wrote:
http://worldnetdaily.com/news/printer-friendly.asp?ARTICLE_ID=41030
An engineer and RFID expert with Intel claims there is
little danger of
unauthorized people reading the new passports. Roy Want
told the newssite:
It is actually quite hard to read RFID at a
My understanding is that once you've used trial division to
get rid of all the extremely short divisors, a random number
of length n is about as hard to factor as an RSA modulus of
the same length. I don't think there are a lot of easy-to-factor
moduli around.
William
-Original
To be more precise: Your odds of getting a modulus that
you can divide by something are very high. Your odds of
getting a modulus that you can factor efficiently are
very low.
William
-Original Message-
From: Matt Crawford [mailto:[EMAIL PROTECTED]
Sent: Monday, August 30, 2004 11:47
[ Jill ]
Instead, I have a
different question: Where can I learn about SSL?
[ Ian ]
PS: next step is Ferguson Schneier's recent book
which has been described as how to re-invent SSL.
This reminds me: the best tutorial on the security
aspects of SSL 3.0 that I know of is the Counterpane
I wouldn't say that this is a good reason to take
these features out of SSL. But assuming they are
needed is a cautious assumption, and assuming
that SSL meets the needs for replay integrity
makes even less sense when we are dealing with a
serious top-to-bottom security model.
[ ... ]
One difference is that with the identity-based crypto, once a sender
has acquired the software and the CA's public key, he doesn't have to
contact the CA to get anyone's certificate. He can encrypt to anyone
without having to contact the CA, just based on the email address.
Your proposed
(I've also posted this message to sci.crypt)
Hi list,
NTRU Cryptosystems has posted several new documents, which are
avaible through http://www.ntru.com/cryptolab/params.htm.
As background: recent results on NTRUEncrypt have shown that
decryption failures on validly encrypted messages leak
30 matches
Mail list logo
