> I'm a bit of a newbie and am trying to get some clarification and better
> understanding on an issue (spurred by Seifred's controversial article):
>
> How does using Stanford SRP solve (or does it?) verification, the MITM
> problem, and need for a CA?
> http://www-cs-students.stanford.edu/~tjw/
I'm a bit of a newbie and am trying to get some clarification and better
understanding on an issue (spurred by Seifred's controversial article):
How does using Stanford SRP solve (or does it?) verification, the MITM
problem, and need for a CA?
http://www-cs-students.stanford.edu/~tjw/srp/project.
Thanks for the clarification Geoff. I see where you're coming from. In my
application it is only the single instance of the application's private key
that really needs protecting. The per-worker-thread public keys are never
shared across threads and therefore don't need to incur the cost of the
Geoff touches on (actually, implies :) some good points.
Again, I want to point interested folks to the following:
http://gatekeeper.dec.com/pub/DEC/SRC/research-reports/abstracts/src-rr-035.html
Written by Andrew Birrell in 1989, 35 highly readable pages. The abstract:
This paper provides a
Hi,
On Wed, 20 Dec 2000, Reddie, Steven wrote:
> The problem with only locking during the assignment is that potentially
> mutliple threads will be doing [extensive] work that will be thrown away
> when they discover that another thread beat them to it. The result could be
> that the lock is he
Zeo Bartoli wrote:
>
> Hi,
> i am trying to parse a pkcs#5 encrypted pkcs#8 private
> key. it is B64 encoded, with -BEGIN ENCRYPTED
> PRIVATE KEY- as a name, but no header info, using
> the following command:
> openssl pkcs8 -in keyfile
>
> i am getting an error:
> Warning: broken key en
Hi,
i am trying to parse a pkcs#5 encrypted pkcs#8 private
key. it is B64 encoded, with -BEGIN ENCRYPTED
PRIVATE KEY- as a name, but no header info, using
the following command:
openssl pkcs8 -in keyfile
i am getting an error:
Warning: broken key encoding: No Octet String in
PrivateKey
t
The problem with only locking during the assignment is that potentially
mutliple threads will be doing [extensive] work that will be thrown away
when they discover that another thread beat them to it. The result could be
that the lock is held for less time, but all threads do more work and
theref
On Mon, Dec 18, 2000, [EMAIL PROTECTED] wrote:
> bodo18-Dec-2000 17:36:11
>
> Modified:.Tag: OpenSSL_0_9_6-stable CHANGES
>crypto/rsa Tag: OpenSSL_0_9_6-stable rsa_eay.c
> Log:
> Obtain lock CRYPTO_LOCK_RSA before creating BN_MONT_CTX
> structures and
Hi everybody,
I just wanted to point out a trap, which I encountered. I am developing an SSL
enhancement
for our SMTP interface and I am using
OpenSSL. I start testing under Win2000 and everything worked fine. After that I tried
it
out under NT4.0 (SP6) and the application hang up
on SSL_connec
On Mon, Dec 18, 2000 at 12:27:45PM -0500, Tom Biggs wrote:
[...]
> Then it says "The ability to send v2 ClientHello messages will
> be phased out with all due haste" etc. Good thing too.
> But has it happened?
>
> How many browsers still do this? I guess some old ones
> are still doing this,
On Mon, Dec 18, 2000 at 12:56:21PM -0800, Geoff Thorpe wrote:
[...]
> What if the code was structured as follows;
>
> if((rsa->_method_mod_n == NULL) && [etc])
> {
> BN_MONT_CTX *bn_mont_ctx;
> int bailout;
> if((bn_mont_ctx=BN_MONT_CTX_new()) == NULL)
>
12 matches
Mail list logo
