Forwarded message:
From: "Jack Cole" <[EMAIL PROTECTED]>
Subject: IEEE 1667 Approved December 5, 2006
Date: Wed, 24 Jan 2007 13:57:15 -0500
Reply-To: "Jack Cole" <[EMAIL PROTECTED]>
IEEE Press Release at
http://standards.ieee.org/announcements/pr_IEEE1667_new.html
IEEE 1667, "Standard Protocol
At 8:22 PM -0500 1/23/07, Ivan Krstiç wrote:
Perry E. Metzger wrote:
http://www.csrc.nist.gov/pki/HashWorkshop/index.html
I'm completely unfamiliar with the way NIST operates, but I've been
wondering for years why they haven't organized this competition already.
Do we have a list veteran who
--
Perry E. Metzger wrote:
> It used to be that Verizon (my local phone company,
> sadly) had this general problem but you could click on
> "log in" and it would direct you to a secure page with
> a little error message and you could then enter your
> username and password. They've since "fixe
On Tue, Jan 23, 2007 at 08:47:26PM -0600, Travis H. wrote:
> This is not really typical of the traffic on this list, hence the OT.
It is much more typical of openssl-users, which is probably a better
bet for this question.
> Recently I had an issue where Google checkout would not accept an
> SSL
Am Dienstag, den 23.01.2007, 20:47 -0600 schrieb Travis H.:
> Verify return code: 21 (unable to verify the first certificate)
> ---
> DONE
>
> I can't seem to get that certificate chain to have any contents other
> than what you see above, no matter what I do, and hence can't get rid
> of the
Hi,
you should provide the whole chain starting from the CA that issued the server
cert. Be careful, though, because you should *NOT* provide the root cert
in the chain as well.
Moreover you should use the:
SSLCertificateChainFile
not the SSLCACertificateFile (which is for client auth)
David Wagner wrote:
[snip]
Another possible interpretation of (2) is that if you use LRW to encrypt
close to 2^64 blocks of plaintext, and if you are using a 128-bit block
cipher, then you have a significant chance of a birthday collision,
Am I doing the math correctly that 2^64 blocks of 1
The wikipedia page on the IEEE SISWG debate about LRW says:
"[A] general security requirement for any block cipher, regardless of
mode of operation, is that no block cipher should be used to encrypt
any more data, without changing the key, when the probability of a
collision becomes not negligible
=?UTF-8?B?SXZhbiBLcnN0acSH?= <[EMAIL PROTECTED]> writes:
>Perry E. Metzger wrote:
>> http://www.csrc.nist.gov/pki/HashWorkshop/index.html
>
>I'm completely unfamiliar with the way NIST operates, but I've been wondering
>for years why they haven't organized this competition already. Do we have a
>li
Travis,
> I can't seem to get that certificate chain to have any contents other
> than what you see above, no matter what I do, and hence can't get rid
> of the Verify return code: 21... does anyone have any advice on what
> to do next? URLs or references to other mailing lists welcome.
maybe th
On Wed, Jan 24, 2007 at 03:28:50PM -0800, Allen wrote:
>
>
> David Wagner wrote:
>
> [snip]
>
> >Another possible interpretation of (2) is that if you use LRW to encrypt
> >close to 2^64 blocks of plaintext, and if you are using a 128-bit block
> >cipher, then you have a significant chance of
To clarify a couple of points with regard to IEEE P1619 and LRW.
The original proposal which P1619 called "LRW" was actually a particular
concrete instantiation of a general construction from the LRW paper
(Liskov, Rivest and Wagner, Tweakable Block Ciphers, Crypto 02,
http://www.cs.berkeley.edu/~
12 matches
Mail list logo
