Re: [openssl-dev] MD5 speed

[Michael Sierchio]

On Sun, Jan 29, 2017 at 10:53 PM, Peter Waltenberg 
wrote:

>
> No one cares ?.


I was rather thinking the same thing. Pretty much the same deprecated
status for SHA1, too.

Want to talk about poly1305?

- M
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] X25519 is the default curve for ECDHE in OpenSSL 1.1.0

[Michael Sierchio]

On Fri, Sep 16, 2016 at 8:52 AM, Salz, Rich  wrote:

...

That's because most people have not moved to OpenSSL 1.1.0 yet.  I'm not
> joking, I think that's a major reason.


Well, you've provided them with a reason. ;-) Srsly, thanks for not making
the NIST curves the default.

- M

-- 
"Well," Brahma said, "even after ten thousand explanations, a fool is no
wiser, but an intelligent man requires only two thousand five hundred."

- The Mahābhārata
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] 3DES is a HIGH-strength cipher?

[Michael Sierchio]

I think you should revert to your earlier comment - that High, Medium, Low
are inherently awful. Maybe color codes? ;-)

I consider 3DES-EDE to be adequately strong. The block size is a problem,
speed in software is a problem, etc. but it has been remarkably resilient
against differential cryptanalysis and other attacks.

- M

On Fri, Feb 12, 2016 at 1:29 PM, Salz, Rich  wrote:

>
> > Well, it would be a major compatibility break for 1.0.2 and earlier, so
> no go
> > there.  As for 1.1.0, folks
>
> Or those who trust us to say what HIGH means should, well, not be lied to.
>
> Something must be changed for 1.1  Either 3DES moves out of HIGH or the
> definition of HIGH as documented in the manpage must change.
> --
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] curve25519

[Michael Sierchio]

On Sun, Jun 21, 2015 at 3:00 PM, Salz, Rich rs...@akamai.com wrote:

 Your analysis is incorrect for servers over the Internet, where the only
 thing that an attacker can measure is time.  Power and radiation require
 close proximity and, often, physical intervention. Those are reasonable
 attacks to have in the threat model, but comes after timing considerations.


Timing attacks, as Rich notes, can be done remotely.  Power and radiant
energy measurements are infeasible in the case of remote servers, esp. in
the case of EC2 instances.  The right design goal was adopted in the case
of curve25519 - as you would expect of Dan Bernstein.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: OpenSSL roadmap

[Michael Sierchio]

On Wed, Jul 2, 2014 at 11:23 AM, Loganaden Velvindron
logana...@gmail.com wrote:

 If I'm interested in fixing OpenSSL, why shouldn't I have access to
 coverity scans ?

I'm not a committer, and not a core member, but I am fully prepared to
answer your question. Because the policy of the project says so. If
you show the dedication and commitment to give back to the project and
become a committer, that could change.

 Other Open Source projects have provided me access to their coverity
 scans, despite the fact that I'm not a committer.

That is deeply flawed as an argument, both rhetorically and materially.

- M
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: AW: Which platforms will be supported in the future on which platforms will be removed?

[Michael Sierchio]

On Tue, Jun 3, 2014 at 7:10 AM, Theodore Ts'o ty...@mit.edu wrote:

 There's a very simple solution to that problem, especially since we
 now have the support and attention of many hardware companies.  The
 rule should be very simple.  If a company doesn't contribute either
 (a) exclusive, dedicated hardware, or (b) reliable, continuous access
 to hardware, it doesn't get supported by the OpenSSL developers.
 Period.

[ details schnipped ]

Hi, Ted. This is lucid, cogent advice. I hope everyone reads this twice.

The most constrained resource is developer time, and it should
prioritized based on some calculus that includes an awareness of which
versions on which platforms have what level of deployment, an internal
roadmap that serves as a strategic guide, and resources made available
by companies that need custom or embedded versions.

The roadmap is key - it needs to include, as Rich Salz took the
trouble to point out, a clear declaration of EOL for the entire matrix
of versions x platforms. Without that, assigning priority to features
in new versions is a promise without real commitment.  In addition to
a public roadmap, a disciplined approach to managing feature backlog
is key for the developers and committers.

While we're full of good ideas for innovation and improvement, let's
not forget the committed efforts of those who continue to shepherd the
project, especially Stephen Henson, who has kept it together in much
the same way as Keith Richards did the Stones.

- M
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: Regarding porting AES ciphers alone to kernel

[Michael Sierchio]

On Thu, Aug 29, 2013 at 10:24 PM, Elluru, Krishna krishna.ell...@netapp.com
wrote:

 HI Openssl dev team,
 We are looking for porting AES Cipher suite alone to kernel for a
requirement.

What platform?  Linux and BSD support /dev/crypto, which is pretty much
what you want.  Support exists for HSMs.

- M

Re: AES GCM considerations in regards to SP800-38D

[Michael Sierchio]

On Sun, Aug 18, 2013 at 2:08 PM, Ben Laurie b...@links.org wrote:


 On 15 August 2013 09:21, Tomas Mraz tm...@redhat.com wrote:

 ...
 Especially there is no checking that the key is not used with more than
 2^32 different IV values. Did I overlook it and the test is there? Or is
 the test not needed because in real life situation this cannot happen? I
 suppose it might happen if the key is not renegotiated during lengthy
 connections with transfer of data in TB range?


 How would you propose that the code tests this property?


 I hope Tomas appreciates your grandmotherly kindness, Ben.  Or the
Socratic method. ;-)

- M

Re: OCB Authenticated Encryption

[Michael Sierchio]

Does Phil still teach at UC Davis?  You could always ask him directly
for clarification or a waiver.

- M
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: ECDSA_do_verify()

[Michael Sierchio]

Kirk81 wrote:
 Sorry guys, I found some mistakes in my code. 

Not just in your code

 So finally, with an IA-32 Pentium M processor 1500MHz, the functions are in
 order of microseconds [ms]:

ms denotes milliseconds.  us denotes microseconds, unless you
can express it as μs, which is obviously preferred.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: SPARC assembly trick in libcrypto breaks IBM Rational Purify

[Michael Sierchio]

Ger Hobbelt wrote:
 On Mon, Mar 16, 2009 at 10:23 PM, Kenneth Robinette
 supp...@securenetterm.com wrote:
 You need to take this discussion offline.
 
 snif Finally something interesting to read and it's mentioned it
 should go. sigh. Here's two who know their craft, it's even about
 OpenSSL and it has given me joy these days, just by reading this. This
 wins over FAQable question posts any day.

Gerrit -

I agree with you completely.  Some actual nitty-gritty is good to read.

- Michael
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: q and j parameters for Diffie-Hellman

[Michael Sierchio]

Dr. Stephen Henson wrote:

 One other note. Static-static DH IIRC has an unfortunate side effect: the
 sender can be traced because they have made use of their private key. Other
 algorithms such as RSA or ephemeral-static DH don't have this property.
 
 This issue was discussed in the S/MIME mailing list at the time.

DH is still extremely useful, particularly with ECC, particularly
for encryption and pairwise authentication.

See dnscurve.org for an example, but also for a novel mechanism for
communicating the public key (essentially an identity encryption
scheme in which the FQDN contains the public key).

It is never necessary to use the long term shared secret directly,
there are mechanisms for permuting it based on the use of a nonce
and coarse-grained timer, a la SKIP.

- Michael (Diffie-Hellman aficionado)
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: David is off to the entropy store to get some fresh entropy

[Michael Sierchio]

biswatosh chakraborty wrote:

Michael, u need more training in communication and then probably in 
technology.


I'm extremely impatient with the use of ill-defined terms
by the less-than-well informed when they pretend to speak
with authority.  Schwartz has committed a number of bald
assertions over the years that are simply untrue (cf. the
thread some time ago wrt SSLv3 being vulnerable to MITM),
and others (such as the repeated invocation of truly random)
which serve only to mislead the earnest but naive reader.

The Humpty Dumpty school of rhetoric (when I use a word,
it means what I want it to mean) is not appropriate to
a technical forum,  would you not agree?

Go and ponder before responding, I'm trying to keep my
killfile down to a manageable number. ;-)

- M

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: Couldn't obtain random bytes in sshd - problem in RAND_poll?

[Michael Sierchio]

Are you or are you not the same David Schwartz who claimed that SSLv3 is
vulnerable to MITM?  If so, what have you learned since then?
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: Couldn't obtain random bytes in sshd - problem in RAND_poll?

[Michael Sierchio]

Theodore Tso wrote:


As the old saying goes, better to be silent, and thought to be a
fool, and to speak, and remove all doubt.


Well, Brahma said, even after ten thousand explanations, a fool is no
wiser, but an intelligent man requires only two thousand five hundred.

Normally, I am fine with people believing all manner of silly things,
but not when they offer advice to others.

- M
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: David is off to the entropy store to get some fresh entropy

[Michael Sierchio]

David Schwartz wrote:


No, we count on it [RSA] being (for practical purposes) irreversible. That's 
why you need a different key to decrypt than you used to encrypt. If it was 
reversible, like say DES, you could decrypt with the same key you encrypted 
with by simply reversing the process.


You are truly clueless.  Encryption and decryption make RSA reversible.  Plonk.


__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: Couldn't obtain random bytes in sshd - problem in RAND_poll?

[Michael Sierchio]

David Schwartz wrote:

 Deterministic is the antithesis of truly random. 


You've said some truly stupid things, David, but that one
wins the prize.


__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   [EMAIL PROTECTED]

David is off to the entropy store to get some fresh entropy

[Michael Sierchio]

David Schwartz wrote:

 Deterministic is the antithesis of truly random. 


I think you're obliged to define what you mean by truly random  --
maybe even think about it before using such terms.

Most processes that generate random noise don't usually have
an nice, equiprobable, Poisson distribution.  So what's truly
random?  I don't think you know.  I'm not sure about your
understanding of deterministic, either.

Is the latched output of a free-running oscillator and a clock
truly random?  Thermal noise?  Radioactive decay?

The distinction you make, with ill-defined and poorly understood
terms, is specious.  Among the mind-blowingly stupid things you've
said in this thread:

So /dev/random tries to provide truly random numbers while
/dev/urandom tries to provide only cryptographically-secure
pseudo-random numbers

It's as assured by the implementation as RSA assures that
its operations are irreversible.

Well, these statements are false.  I leave it up to you to decide
whether such utterances are, on their face, stupid.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: David is off to the entropy store to get some fresh entropy

[Michael Sierchio]

David Schwartz wrote:

It's a well-understood term in the art. 


You are not a practitioner of the art, David.  There are RBGs and
PRBGs but no one uses the term truly random.


In fact, it's the same distinction everyone else in this field makes.


No.  We know what cryptographically useful random bitstreams are.


So /dev/random tries to provide truly random numbers while
/dev/urandom tries to provide only cryptographically-secure
pseudo-random numbers


This is, in fact, precisely correct. The man page says:


Um, no mention of truly random.  Ted T'so will chime in here...


  A  read  from  the  /dev/urandom device will not block waiting for more
  entropy.  As a result, if  there  is  not  sufficient  entropy  in  the
  entropy  pool,  the  returned  values are theoretically vulnerable to a
  cryptographic attack on the algorithms used by the  driver.  


But you said it was cryptographically secure (not a term of art, btw).


If you don't know anything about an entire field, the least you can do is keep 
your mouth shut.


Good idea, David.  You've demonstrated a depth of ignorance that
is truly profound.  Time to shut up.  I noticed you skipped right over
my citing your claim that RSA is irreversible.



__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: Couldn't obtain random bytes in sshd - problem in RAND_poll?

[Michael Sierchio]

David Schwartz wrote:

 do disagree with my claim that an algorithmic process can
 produce an very large amount of cryptographically-strong
 random output with a small amount of truly random input?

Yes.  A small amount of random input might mean that the
entire state -- past, present and future -- of the PRNG
can be known by guessing the initial input.

Back to school, David, back to school.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: David is off to the entropy store to get some fresh entropy

[Michael Sierchio]

David Schwartz wrote:


RSA is reversible. I never claimed otherwise. What I said is: So /dev/random tries 
to provide truly random numbers while /dev/urandom tries to provide only 
cryptographically-secure pseudo-random numbers. It's as assured by the implementation as 
RSA assures that its operations are irreversible.

This is precisely correct. In both cases, the operations are possible in theory 
but impossible in practice -- by careful and deliberate design.



David, we count on RSA being reversible, that's how it's designed.  One-way
hash functions are presumably irreversible.  Your knowledge of cryptography
hasn't improved, you should go home now.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: David is off to the entropy store to get some fresh entropy

[Michael Sierchio]

David Schwartz wrote:


Apparently you don't understand the relationship between true randomness and 
entropy.


I don't know what you mean when you say true randomness and I suspect
that you don't.

When you use the word entropy in this context, I assume you mean Shannon
entropy, and I'm pretty sure you don't have an adequate understanding
of that either.



__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: IPv6 support in OpenSSL

[Michael Sierchio]

Ravindra wrote:


I'm looking for information regarding IPv6 support in OpenSSL.
Which is the first and stable version that adds support for IPv6 in OpenSSL ?


SSL operates atop TCP.  Whether this supports IPv6 is left as an exercise
for the reader.

- M

PS  Does your web browser support IPv6?  Does your monitor?  How about
your keyboard?
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: [CVS] OpenSSL: openssl/crypto/x509/ x509_att.c

[Michael Sierchio]

Geoff Thorpe wrote:


On Friday 30 May 2008 09:52:40 Ben Laurie wrote:



Dr. Stephen Henson wrote:



I do wish you wouldn't use these extra brackets around comparison
operators.

if (len == -1  !(attrtype  MBSTRING_FLAG))

works just fine and is consistent with most of the rest of the code, and
the rest of the world.


I find Steve's version more readable.


Agreed.  Cleverness is not a virtue here, unless this is a programming
contest.  Very few programmers remember that , ^, |,  and || have
different precedence (and in the order in which I enumerated them)
and which ones associate left-to-right versus right-to-left.

When two expressions evaluate to the same value, a useful question to
ask is: which version reduces the cognitive load on the reader by
reducing ambiguity or error?

- M
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: valgrind and openssl

[Michael Sierchio]

Thor Lancelot Simon wrote:


... However, consider the pathological case,
in which an adversary manages to introduce N-1 bits of known state into your
PRNG which has N bits of internal state.  ...


What you seem not to understand from this discussion is that the
internal state is a consequence of input that is processed via
a diffusion mechanism, a cryptographic hash such as SHA1 or MD5
or something stronger.  These change roughly half the bits of
their output when a single input bit is changed.

It is not possible to know the state itself without direct inspection
of structures whose security is obviously essential for useful
random number generation.

If your point is that system events are not a good source of
entropy, I agree.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: valgrind and openssl

[Michael Sierchio]

Theodore Tso wrote:

 ... I'd be

comfortable with an adversary knowing the first megabyte of data fed
through SHA1, as long as it was followed up by at least 256 bits which
the adversary *didn't* know.


I'd be comfortable with an adversary knowing the first zetabyte of
data fed though SHA1, as long as it was followed up by at least 256 bits
which the adversary didn't know. ;-)

Cheers,

Michael

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: 117 Character Limit

[Michael Sierchio]

robert2007 wrote:

I noticed that using RSA with OpenSSL places a 117 character limit when
encrypting messages.  Would anyone happen to know the reason for this?


1) It doesn't

2) Do you mean with a 1024-bit modulus the encryption block size
is 936?  Because of padding.

If one were to Wiki and/or Google terms like OAEP or
Optimal Asymmetric Encryption Padding ...

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: 117 Character Limit

[Michael Sierchio]

Goetz Babin-Ebell wrote:


RSA has some weaknesses against chosen plain text attacks.


RSA is just an algorithm, so if you talk of chosen plaintext
or chosen ciphertext attacks, it needs to be in the context
of an encryption method.  OAEP is a response primarily to
a chosen ciphertext vulnerability using RSA with the original
PKCS padding.

Which is why I assigned the poster a reading assignment.

If one were to Wiki and/or Google terms like OAEP or
Optimal Asymmetric Encryption Padding ...

It's more subtle, too -- read Victor Shoup's paper
_OAEP Reconsidered_.

I suppose I could have given an even more terse answer
and said padding -- but the need to pad isn't obvious
to the casual observer.

Anyway, why would someone use RSA for encryption? ;-)

- Michael
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: OpenSSL and LSB

[Michael Sierchio]

Theodore Ts'o wrote:


Reading through the mail archives, the problem, as I understand
it, is that OpenSSL is derived from a very old legacy codebase, with an
interface which relies on publically visible data structures which must
be accessed either directly, or via accessor macros.  In some cases,
those macros could be changed to accessor functions, and it looks like
the easy cases have been done --- but in other cases, the macros
couldn't be replaced with accessor functions without causing an API
change which would breaking applications.  Is that a fair summary of the
situation?


It is *so* difficult to critique something without seeming to
criticize the work of others, so the following disclaimer applies.
MUCH is owed to the developers and maintainers of OpenSSL --
Mark, Ralf, Stephen, Ben, Lutz, Nils, Richard, Bodo, Ulf, Andy,
Geoff -- and a host of others.  OpenSSL is ubiquitous, thanks in
large part to them.  108 bows to each of you.

OpenSSL derives from Eric Young's work of many, many years ago.  It has
come to resemble a tarmac that is mostly patches.  Yes, yours is a fair
assessment.

My first impression (On first looking into Chapman's Homer) was --
wow, it really *is* painful to write C++ in C.  That was more than
a decade ago.

If one were really serious, it calls for a rewrite -- one that replaces
the dreadful BIO-stuff, develops a strictly modular separation of crypto
libraries (which are used so many places other than for SSL/TLS), etc.
and is written in C++.

Just my USD 0.02^H1^H05

- Michael
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: Hiding headers for OpenSSL

[Michael Sierchio]

Scott Campbell wrote:

 The long version:  We run security check software, which makes 
connections with various services, calls up the header, and then tells 
us that based upon the version it read in the header, this service has 
certain vulnerabilities.  For security purposes, we would like to 
disable the broadcasting of headers so outside users cannot simply call 
up the header and see what version we're running.  Additionally, the 
vulnerabilities are wrong since the header is one thing but the revision 
numbers indicate that the vulnerabilities have been resolved (those 
using RedHat RHEL should be familiar with this issue).  What I want to 
do is prevent outside connections from seeing any version information, 
in order to give potential abusers as little information about our 
system as possible.


It sounds as if you're approaching this in a bass-ackwards way.

First - fix the false positives in your vulnerability reporting.

Second - the bid for security through obscurity in not reporting
the version number seems misguided to me.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: Propose replacing POD with DocBook

[Michael Sierchio]

Richard Salz wrote:

I propose that OpenSSL move to DocBook


FWIW, I emphatically support this proposal.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: Propose replacing POD with DocBook

[Michael Sierchio]

Richard Salz wrote:

FWIW, I emphatically support this proposal.


Thanks!

Hope you're doing well.


I am, thanks.  How are you?  You sorta dropped low on the
radar for a while.

I used to joke: XML: the new ASN1!  But I'm happy to be
wrong about that.  Anything -- and I include a clay tablet
and cuneiform implement -- is better than gnuinfo and POD.

I'm trying to do security and privacy consulting, and find
it's really a form of business process reengineering.
Computers and networks are easy,  data classification, policy,
work methods are hard.

Cheers,

Michael
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: Propose replacing POD with DocBook

[Michael Sierchio]

Sorry folks, my MUA caused that to go to the list instead of
just Rich.

Cheers,

Michael


__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: ideas on replacing where ERR_STATE is stored?

[Michael Sierchio]

Steven Reddie wrote:

Hi Michael,

I'm familiar with that approach, having used it many times myself.  The
choice of poll over select isn't important since they're basically the same;
in fact, poll is sometimes implemented with select.  


Who implements poll with select should suffer a fate worse than
death -- waking up a thousand sleeping threads to see if one
has some i/o ready is what poll was designed to avoid.

But that's just my opinion...
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: ideas on replacing where ERR_STATE is stored?

[Michael Sierchio]

Jack Lloyd wrote:


I believe Michael is actually talking about the thundering herd problem, when
many processes are all waiting on a single event, which only one of them will
end up responding to. That is a classic problem affecting some uses of select
(and also accept, and IIRC a few other socket calls as well).


Precisely what I was thinking, though I suppose I should have
actually said it. ;-)  Thanks.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: ideas on replacing where ERR_STATE is stored?

[Michael Sierchio]

Lev Walkin wrote:

 ... Poll() provides no advantage over select()

for the thundering herd problem.


Sorry, I'm not here to chew your food for you.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: ideas on replacing where ERR_STATE is stored?

[Michael Sierchio]

Lev Walkin wrote:


Including poll().


A polling model may be built on /dev/poll or kernel queues, etc.
I made mention of /dev/poll in my first contribution to this
thread.  Go back to class.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: ideas on replacing where ERR_STATE is stored?

[Michael Sierchio]

Steven Reddie wrote:

Do you mean using select() to handle multiple simultaneous connections?


I'm late in catching this thread, but I'll wager that Rich would
use poll rather than select, or /dev/poll, or some such.  The
model he describes is the most efficient, but makes application
programming harder - essentially trading off the ease of single-task
worker threads for higher performance, but having to write a state
machine.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: [openssl.org #1176] Problems wirh openssl-0.9.8, make test

[Michael Sierchio]

Andy Polyakov via RT wrote:

Similar problem was reported in FreeBSD context and is believed to be 
caused by a bug in binutils. You either have to upgrade binutils or 
reconfigure with extra no-sse2 option. ...


If you make an entry in the FAQ, please be specific about which
versions of the GNU binutils are broken.  In fact, it might
even be helpful to have a list of toolchain versions that
are known to work -- model success, rather than failure! ;-)

Thanks,

Michael

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: Inclusion of FIPS

[Michael Sierchio]

Ben Laurie wrote:
My understanding is that our security policy is that if you can show a 
chain of SHA-1 HMAC signatures from the certified source to 
whatever-it-is-you-are-running, then you are certified. We provide one 
mechanism to do that. You can provide others.

Note that the chain of signatures is _not_ intended to handle malicious 
intent. It is there to make it difficult to think you are certified when 
in fact you are not.
How is an HMAC-SHA1 digest a signature?
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Accelerating RSA Key Generation

[Michael Sierchio]

Bommareddy, Satish (Satish) wrote:
HI
 
One of the applications we are working on requires us to generate RSA key pairs at a rate of about 20-25 key pairs/second
is there any application out there which can do this??
is using /dev/random, /etc/entropy or accelerator card with RNG any faster?? and can this achieve the speed we require?
Assume for the moment you have an infinite supply of good random
numbers.  You still have a compute-bound problem when generating
key pairs.
You want to randomly generate two numbers p1, p2 in the range

	[2^(n-2) * sqrt(2),   2^(n-1)]

in order to get L(p1*p2) == 2n bits.

Tests for primality are time consuming, and some time is spent
building the CRT components and deriving d from e.   It's all
Big Number Arithmetic, and accelerator cards won't help.
Buy a nice new dual-processor G5. ;-)

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Accelerating RSA Key Generation

[Michael Sierchio]

Dr. Stephen Henson wrote:

What's the intended purpose of the keypairs? If you don't have to use RSA then
other public key algorithms could be used which have must quicker key generation
times.
Yep.  A DH keypair is as fast as generating N random bits and doing a
single modular exponentiation -- which *can* be done by an accelerator.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: FIPS mode

[Michael Sierchio]

Mathias Brossard wrote:

It's a little disappointing that RSA is not part of the process (it is
much more common than DSA). Looking at the list of validated modules
http://csrc.nist.gov/cryptval/140-1/1401val.htm I see in the field
FIPS-approved algorithms the value RSA (PKCS #1, vendor affirmed).
Will you as a 'vendor' claim that OpenSSL is compliant with RSA PKCS#1 ?
I believe that this is an artifact of the policy being adopted while
the RSA patent was in force.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: More DH questions

[Michael Sierchio]

Nils Larsch wrote:

Is it true that for a given P  g, I would always get the same public key


No, the private key is (should be) a random number = you get a different
public key for each invocation of DH_generate_key
Not quite, no.  In fact, DH would be pretty useless if that were
the case.  See my code snippet, if you fill in the private exponent
(which is what I assume you mean by private key),  you'll always
get the same public exponent if the private exponent is the same.

What could be the possible problem where I am getting a different secret 
pub_key every time?
Perhaps you should read a textbook about cryptography.
I think the problem may be the less-than-intuitive API.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: More DH questions

[Michael Sierchio]

Bala Pitchandi wrote:

Is it true that for a given P  g, I would always get the same public key
and for a given P, g  pub_key, I would get the same shared secret key?
Okay, let's get a few terms straight.  With Diffie-Hellman, a system
shares g, p and each user generates a random secret exponent, x.  g^x mod p
yields the public exponent.  Given any two users whose publice exponents are
X  Y, and who share g, p,  they may calculate the pairwise shared secret as
follows
One party calculates X^y mod p
the other calculates Y^x mod p
and thanks to the properties of algebra, these two are the same.

Is that what you mean?

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: More DH questions

[Michael Sierchio]

Bala Pitchandi wrote:

Yes, I do understand the DH exchange process. But with respect to the
OpenSSL DH Library usage, let's say I and another party have fixed p  g. I
calculate X using DH_generate_key() (I get a different X every time for the
same p  g, is that okay?). And later I receive the other party's Y (which
never changes by the way) and use it to calculate the secret key and is
different every time. So my comparison against their shared secret key
fails.
The function for calculating the shared secret is DH_compute_key().

Here's a starting code snippet, mostly lifted from the examples
for OpenSSL:


#include stdio.h
#include stdlib.h
#include string.h
#include time.h
#include sys/time.h
#include openssl/crypto.h
#include openssl/bio.h
#include openssl/bn.h
#include openssl/dh.h

int main(int argc, char *argv[])
{
/*
unsigned char apriv[] = { 0x00,
0x8d, 0x3a, 0x22, 0x0b, 0x78, 0x98, 0x51, 0x0b,
0xe2, 0x98, 0x77, 0xc0, 0xa8, 0x15, 0xf3, 0x91 };
/**/
/**/
unsigned char apriv[] = { 0x00,
0x23, 0xf9, 0x2c, 0xd5, 0x25, 0xb1, 0x78, 0xcb,
0x13, 0x57, 0x31, 0x9c, 0x1a, 0x53, 0x5c, 0xb4,
0x8d, 0x3a, 0x22, 0x0b, 0x78, 0x98, 0x51, 0x0b,
0xe2, 0x98, 0x77, 0xc0, 0xa8, 0x15, 0xf3, 0x91 };
/**/
unsigned char bpub[] = { 0x00,
0xd9, 0x64, 0xc9, 0xda, 0x12, 0x65, 0x5f, 0xf3,
0x07, 0x7a, 0x32, 0x13, 0x6f, 0xfc, 0x65, 0x66,
0x62, 0x0e, 0xaf, 0xef, 0xa2, 0x3e, 0x5e, 0x6d,
0xbf, 0xbe, 0x27, 0xfd, 0xc2, 0xc4, 0x4d, 0x74,
0x39, 0x7d, 0x36, 0x76, 0xe2, 0x71, 0xf3, 0x10,
0x38, 0x7d, 0x2c, 0x55, 0x12, 0x5b, 0x91, 0x49,
0x2f, 0xdf, 0xe3, 0x84, 0xbf, 0xfd, 0x15, 0x7c,
0xe8, 0x96, 0x3f, 0x0f, 0x4e, 0x7a, 0x42, 0x27,
0x96, 0xa8, 0x81, 0x16, 0x83, 0x7b, 0x53, 0xe5,
0x14, 0x29, 0x30, 0x34, 0x93, 0x6f, 0x4f, 0x9e,
0x49, 0xd3, 0x71, 0x9e, 0xde, 0xc6, 0x23, 0x6c,
0xc6, 0x3d, 0xcf, 0xed, 0x08, 0x98, 0x1f, 0xf4,
0x0b, 0xa7, 0xd9, 0xbe, 0x51, 0x38, 0x36, 0x9b,
0xb2, 0x7c, 0x92, 0x76, 0x97, 0xe2, 0x47, 0xb3,
0x7d, 0x55, 0x66, 0x12, 0x5b, 0x29, 0xf5, 0x75,
0x4c, 0x4d, 0x71, 0x4b, 0x26, 0x53, 0x54, 0xe7 };
unsigned char primo[] = { 0x00,
0xe1, 0x95, 0x37, 0xa2, 0xbf, 0xe3, 0x13, 0x9e,
0x89, 0xf6, 0x4f, 0xf9, 0x26, 0x71, 0x03, 0x80,
0x1b, 0x73, 0x7b, 0x8e, 0xe7, 0xe8, 0x7e, 0xc0,
0xd1, 0x60, 0x10, 0x77, 0xf7, 0xf1, 0x26, 0x0c,
0xef, 0x67, 0xc1, 0x00, 0x67, 0xd3, 0x8d, 0x84,
0x2b, 0x23, 0x8b, 0x8b, 0xbb, 0x72, 0xd3, 0xfb,
0x80, 0x57, 0x17, 0x2e, 0x3c, 0x5f, 0x1e, 0x28,
0x4b, 0x87, 0x27, 0x6e, 0xe6, 0x87, 0x6f, 0x6a,
0xb8, 0x45, 0x8d, 0x28, 0x3a, 0x0d, 0x88, 0xd1,
0x1c, 0x74, 0xb3, 0xf8, 0x2c, 0xd2, 0x81, 0x60,
0x7e, 0xc1, 0x77, 0x8b, 0x2d, 0xe0, 0x58, 0xc8,
0x78, 0xe7, 0xaa, 0x81, 0x07, 0xc3, 0x32, 0xce,
0xb4, 0x16, 0xaf, 0x74, 0xd7, 0xee, 0x95, 0xee,
0xbf, 0x8d, 0xcb, 0xf0, 0xab, 0x3a, 0x10, 0xd1,
0x3e, 0xb4, 0x61, 0xe5, 0x44, 0x8f, 0x9f, 0x81,
0xae, 0xab, 0x6f, 0xb3, 0x54, 0xb7, 0x56, 0x8b };
DH *a;
BIGNUM *bnbpub;
char buf[256];
unsigned char *abuf=NULL;
int i,alen,blen,aout,bout,ret=1;
BIO *out;
long long   time0, time1;
struct timeval  tv;
out=BIO_new(BIO_s_file());
if (out == NULL) exit(1);
BIO_set_fp(out,stdout,BIO_NOCLOSE);
a=DH_new();
a-p=BN_bin2bn(primo,sizeof(primo),NULL);
a-g=BN_new();
BN_set_word(a-g,2);
a-priv_key = BN_bin2bn(apriv,sizeof(apriv),NULL);
bnbpub = BN_bin2bn(bpub, sizeof(bpub), NULL);

BIO_puts(out,\n\np=\n);
BN_print(out,a-p);
BIO_puts(out,\n\ng= );
BN_print(out,a-g);
BIO_puts(out,\n\n);
if (!DH_generate_key(a)) goto err;
BIO_puts(out,A's private key =\n);
BN_print(out,a-priv_key);
BIO_puts(out,\n\nA's public key =\n);
BN_print(out,a-pub_key);
BIO_puts(out,\n\nB's public key =\n);
BN_print(out,bnbpub);
BIO_puts(out,\n\n);
alen=DH_size(a);
abuf=(unsigned char *)OPENSSL_malloc(alen);
aout=DH_compute_key(abuf,bnbpub,a);
BIO_puts(out,Kab =\n);
for (i=0; iaout; i++) {
sprintf(buf,%02X,abuf[i]);
BIO_puts(out,buf);
}
BIO_puts(out,\n\n);
ret=0;
err:
if (abuf != NULL) OPENSSL_free(abuf);
if(a != NULL) DH_free(a);
BIO_free(out);
return(ret);
}
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: AES counter mode

[Michael Sierchio]

Stephen Sprunk wrote:

I'm a bit more ambitious...  We should specify NIST-style CTR mode for all
octet stream applications within the IETF's domain, with SSL/TLS as an
example.  For record-based systems, I don't know if NIST-style or
IPsec-style would be more appropriate :-(
There is no such thing as NIST-style.  There's Helger Lipmaa's
suggestion, and that's really it.  A 64-bit counter offers the
misleading sense that it is safe to use more than 2^32 blocks
of keystream.
CTR mode offers very little advantage over CBC or CFB or OFB -- the
motivation for IPsec was very high speed, parallel encryption with
precomputation of the keystream (according to the Rt. Hon. Rev.
Bellovin, IETF Security Area co-chair).
Can someone explain why the IPsec folks felt they needed to reimplement CTR
mode, especially in a way which appears to create more problems?
Yes.  SSL/TLS have the advantage of operating over TCP -- where
replay, delayed duplicates, out-of-order delivery, fragmentation,
etc. are all handled magically and elsewhere.  IPsec operates
via a connectionless medium with no delivery guarantees (IP).
Obviously we don't need nonces, just counters.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: AES counter mode

[Michael Sierchio]

Richard Levitte - VMS Whacker wrote:

OK, I've been follownig this discussion for a while, and it's time I
ake action.  Basically, to provide for all the current and future ways
of handling the IV, I can see three alternatives:
- have the application provide a function that manipulates the IV.
- have the application specify exactly which part of the IV is the
  actual counter (in bit positions, or would byte positions be
  enough?).
- a combination of the two (that would make our code extract the
  counters bits and only give those to the provided function, which
  then does the increment in any way it wishes).
There's no need for an IV for SSL/TLS encryption with AES CTR mode.
All that's needed is a counter, and a mechanism to prevent using
more than 2^38 or so bytes of keystream without changing the key.
lee_dilkie (the other thing to remember is that CTR can be used with
lee_dilkie any block cipher, it's not limited to AES)
Absolutely.  
Not quite.  You want to be sure to use block ciphers that are
differentially strong.  AES is particularly well-suited.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: AES counter mode

[Michael Sierchio]

Richard Levitte - VMS Whacker wrote:

Whatever, I used the terms like this:

- IV is a bitstring of some sort (possibly random), of the same size
  as the crypto algorithm block.  In the AES case, it would be 128
  bits.
- For CTR mode, the counter is a part of the IV.  The rest of the IV
  is some kind of random bits (a nonce).
Those are the conditions I'm working from.  Makes sense?
Completely.  If we have confidence in the cipher and the secrecy
of the key, make the nonce all zeroes.  There's good reason for not
doing this in the case of IPsec,  but not for SSL/TLS.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: AES counter mode

[Michael Sierchio]

Lee Dilkie wrote:

I don't have experience with counter mode for SSL (if there is even such a
beast) or the NIST mode you are referencing (I believe Ipsec was looking at
that mode a few months ago) but I do have experience with counter mode for
SRTP (secure RTP; encryption of media streams). In fact, I wrote a counter
mode encryptor/decryptor using the EVP_* functions.
CTR mode is not mentioned in the FIPS 197 document, NIST SP 800-38A
specifies the CTR mode(s).  This is a recommendation document, not
a standards document.  See appendix B.2 for a discussion of CTR
values.  This doc discusses the use of half the 128 bits as a nonce,
and the remaining bits as a counter.
Lipmaa, Rogaway and Wagner is the definitive recommendation for CTR mode
operation, and the mode exists as part of AES (as opposed to Rijndael)
because of Helger's efforts.  They explicitly state
Usage scenarios. In the recommended usage scenario, the party encrypting
maintains an integer counter, nonce, initially 0, and produces the string
ctr as the 128-bit string which encodes the number nonce . 2^64. (In other
words, nonce is regarded as a 64-bit binary number, and ctr is constructed
by appending to this number 64 zero-bits.) The number nonce is incremented
following each encryption.
Using AES Counter Mode With IPsec ESP - This mandates a 32-bit counter,
requiring rekeying after 2^48 octets of stream material.
http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ciph-aes-ctr-04.txt

Argument:  let's write an Internet draft that describes the use
of AES CTR mode in SSLv3/TLSv1.  We can do it however we like, modulo
the usual criticism and review in the IETF working group(s).
Comments?  Rich?  Richard?  Stephen?

--

Well, Brahma said, even after ten thousand explanations, a fool is no
 wiser, but an intelligent man requires only two thousand five hundred.
- The Mahabharata
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: AES counter mode

[Michael Sierchio]

Thierry Boivin wrote:
I agree with you about the way to build the initial ctr value  from the nonce value. My question is different : whithin the encryption of a  whole plaintext message (so a big block to be divided into 128 bit length blocks) , why to increment ctr by 2^64 instead of 1 from block to block ? 

My understanding of the operation is :
- increment nonce by one from messages to messages (so this is a 2^64 step if 
considering ctr)
- but for each message:
- build initial ctr from the nonce value
- increment ctr by 1 from block to block


C'est votre compréhension et non votre accord que nous attendons!

Incrementing by 2^64 is incrementing the most significant 64-bit word by 1.

--

Well, Brahma said, even after ten thousand explanations, a fool is no
 wiser, but an intelligent man requires only two thousand five hundred.
- The Mahabharata
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: AES counter mode

[Michael Sierchio]

Thierry Boivin wrote:
Hello,

I am trying to play with AES crypto in counter mode. Using the crypto library against reference vectors found in IPSec RFC fails until the  incrementation function (AES_ctr128_inc()) is modified in order to get a +1 step instead of a +2^64 step. Where does the actual increment by 2^64 come from ?

Read the documents on AES counter mode.  The counter is a 64-bit
counter but the blocksize is 128, and the convention is that the
counter is a Big Endian number with only the MSW used.
[from Lipmaa, Rogaway  Wagner]

In the recommended usage scenario, the party encrypting maintains an
integer counter, nonce, initially 0, and produces the string ctr as
the 128-bit string which encodes the number nonce * 2^64.
Don't ask me *why* it's that way -- the choice of a mere 64 bits is
clearly done in order to avoid a well-known attack against stream ciphers,
since one can begin to distinguish a stream from random after 2^90 or so
samples.
Maybe the Big Endian choice is a subtle protest against Wintel?

--

Well, Brahma said, even after ten thousand explanations, a fool is no
 wiser, but an intelligent man requires only two thousand five hundred.
- The Mahabharata
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: how to convert a .DER certificate to .DB ?

[Michael Sierchio]

Scott Harris wrote:
 I need some help to change the Certificate I generated using Microsoft 
 Certificate server in .*DER* format to convert to .*DB* format to 
 use with Netscape API. Any body knows *how to convert a .DER certificate 
 to .DB *. Any tools that that can do that..

It's been a while since I used the Netscape 'certutil' and
'keyutil' so I can't say with certainty whether they'll do
the job.

The easiest way, of course, is to use Netscape browser to
load the new cert (with the appropriate MIME type presented
to the browser) and agree to trust it as a trusted signer.


__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: OpenSSL using a TRNG

[Michael Sierchio]

Leif Kremkow wrote:

 I'm looking for some guidance. I'd like to change the OpenSSL library to be
 able to use a TRNG for all random numbers, not just to seed the PRNG.

There are no such devices which produce adequate quantities of random
material for a server with reasonable load.  Most have a variable max
bitrate which seldom exceeds 12k-16k bits/s.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: [PATCH] AES counter mode non-zero counter offset

[Michael Sierchio]

Richard Levitte - VMS Whacker wrote:

 How could num (or n, inside AES_ctr128_encrypt() ever have a value
 that isn't between 0 (included) and AES_BLOCK_SIZE (excluded),

It's even smaller than that.  CTR mode is defined as a BIG-ENDIAN
128-bit number (AES only has one block size) 0 = n = 2^64-1

Chances are you don't want to abuse this -- this mode has not been
studied as much, and it's a good idea to produce considerably less
stream than allowed with a single key.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Why should SPKAC-initiated certificates be stored in raw DERformat

[Michael Sierchio]

Richard Levitte - VMS Whacker wrote:
 I just noticed that when 'openssl ca' is used with '-spkac', the
 resulting ctificate is stored in raw DER format instead if PEM
 format.  Is there a logical reason for this, or is this another
 EAYism that noone understands today?

Since SPKAC was a Netscapism,  it's entirely possible that the
default representation was chosen to be DER because that's how
it must be returned to the browser.  IOW, I have no idea... ;-)

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Openssl-09.5

[Michael Sierchio]

Richard Koenning wrote:

 Look at http://www.openssl.org/support/faq.html#USER

   Pointing $RANDFILE to an Entropy Gathering Daemon socket does not work. ...

This is really a bug.  It doesn't work *why*?  Because the code isn't
written to read properly from a FIFO.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Solaris bc

[Michael Sierchio]

Erwann ABALEA wrote:

 dc and bc are linked by some way...

Yes.  Unlink dc and bc won't work. ;-)

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Solaris bc

[Michael Sierchio]

Howard Chu wrote:
 The last time I checked, dc is only a front-end for bc. It seems odd to me
 that dc can work correctly if bc is broken...

# cd /usr/bin
# ls -l dc
-r-xr-xr-x   1 root bin40584 Jan  5  2000 dc
# ls -l bc
-r-xr-xr-x   1 root bin25600 Jan  5  2000 bc
# chmod 0 bc
# dc
[la1+dsa*pla10y]sy
0sa1
lyx
1
2
6
24
120
720
5040
40320
362880
3628800
^C# uname -a
SunOS blade 5.8 Generic_108528-13 sun4u sparc SUNW,Sun-Blade-100
# chmod 555 bc

And stop top posting!

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Solaris bc

[Michael Sierchio]

Daniel Sands wrote:

 What's the problem here?  The output is exactly as it should be for this
 program.

Your lack of reading skills?  The point is that the previous
poster asserted that dc was a front end to bc.  I believe that I
conclusively demonstrated that this is not the case.  Try again.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: How can i make a symmetric key?

[Michael Sierchio]

Kukmin, Han wrote:

 How can i make a symmetric key using openssl library?

Make a random number.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: bug and solution wrt SSL_set_verify()

[Michael Sierchio]

Nelson Stewart wrote:
 
 REMOVE

Remove what?  Those old rags you're storing in your skull?  You didn't
save the instructions you got when you subscribed, did you?

http://www.openssl.org/support/

And do your best to follow the instructions.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: HOWTO renew a certificate

[Michael Sierchio]

Massimiliano Pala wrote:

 However keep in mind that certificate renewal (issuing a new certificate to
 the same subject using the same key) should be discouraged as its lifetime
 (key's one) should be considered ended with the expiration of the certificate
 (or you could have issued the certificate with a longer validity period,
 don't you think ?), at least to me.

Depends on the key usage, but I generally agree.  There are legitimate
reasons for resigning,  usually because of a DN change (move from
one OU to another in the same O, for example), but the lifetime of the
key should probably not be extended beyond the key in the original
cert.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: RAND_add() and the entropy...

[Michael Sierchio]

Lutz Jaenicke wrote:

 The entropy parameter should tell, how much uncertainty is in the
 data provided.

 If we choose a value of 0, we mean that there may be entropy in it, but
 maybe an attacker can predict the value, so we use it but do not count
 it as a really unpredictable input.

So, if we know the entropy per character (byte) what's the correct
formula for deriving the correct value for the entropy parameter?
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Orders of PKCS7 certificate chain

[Michael Sierchio]

Wang, Kate wrote:
 
 Hi, everyone,
 
 Here is another novice question.
 
 Is there any easy way to find out the subject certificate out of a PKCS7
 certificate included the whole chain?
 
 Or more specifically, if I use openssl PKCS7 command to convert a PKCS7
 certificate into PEM format, or openssl pkcs12 to convert pkcs12 format
 into PEM, can I assume the subject certificate would be the first
 certificate?
 

PKCS#7 is not a certificate.  PKCS#12 is not a certificate.  PKCS#7
defines the Cryptographic Message Syntax -- PKCS#12 defines the
Personal Information Exchange Syntax.  

If a party encodes a certificate chain in a PKCS#7, it's up to whatever
convention is in use to determine whether the subject cert is first.  

A PKCS#12 is a bag.

Presumably you can match on the SubjectName?
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Differences between TLS and SSL

[Michael Sierchio]

Joaquim Quinteiro Uchoa wrote:
 
 I'm needing, urgently, to know the differences
 between TLS and SSL protocols...
 
 I don't need big details, only one or two
 paragraphs about the difference.

SSLv3 was devised by Paul Kocher with Phil Karlton and Alan Frier for Netscape.
TLS is an IETF Standards Track Protocol based on SSLv3.

http://www.ietf.org/html.charters/tls-charter.html

http://home.netscape.com/eng/ssl3/

SSLv3 is a defacto, industry standard, devised by the best cryptanalyst
we have.  It is represented only by an expired Internet Draft. TLS is a
committee effort.  You be the judge.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: NULL fields in RSA structure

[Michael Sierchio]

Ajay Nerurkar wrote:
 
 According to the doc the fields p, q, dmp1, dmq1 and iqmp
 in the RSA structure may be NULL in private keys but the
 function i2d_RSAPrivateKey() calls BN_num_bits() with each
 field of the argument RSA* a. And BN_num_bits() cannot handle
 a NULL argument. So, either BN_num_bits() or i2d_RSAPrivateKey()
 needs to check that it's not dealing with a NULL.

Steve?
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Is Diffie - Hellman used anywhere?

[Michael Sierchio]

Dr S N Henson wrote:
 
 Michael Sierchio wrote:
 
  Dr S N Henson wrote:
 
   DH certificates aren't currently supported: hardly anything uses them.
   The DH algorithm itself is used by (among other things) SSL and TLS.
 
  Mobile IP does.  I suggest again that, since a DH profile exists,
  it should be supported in OpenSSL.
 
 Any sample certificates available?

Wouldn't you rather have the ASN.1 profile?
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Is Diffie - Hellman used anywhere?

[Michael Sierchio]

Dr S N Henson wrote:

  Wouldn't you rather have the ASN.1 profile?
 
 I'd rather have both. If past experience is anything to go by the ASN.1
 profile will show what the certificates should be like and the examples
 will show what they really are like :-)

Yes, and I've already promised you this, but have been buried in work (I
suppose it beats the alternatives:  not having work, or being buried in
rubble).  I'll try to get this to you soon.

There are considerable advantages in doing away with the subgroup
nonsense if you're not doing DSS -- it can strengthen the key agreement
against several forms of attack.

For the hand-waving approach,  the only difference in syntax is 
in subjectPublicKeyInfo --

SubjectPublicKeyInfo  ::=  SEQUENCE  {
algorithm   AlgorithmIdentifier,
subjectPublicKeyBIT STRING  }


AlgorithmIdentifier  ::=  SEQUENCE  {
algorithm   OBJECT IDENTIFIER,
parameters  ANY DEFINED BY algorithm OPTIONAL  }


with the subjectPublicKey defined as the DER-encoding of the DH Public Key   
encoded as an INTEGER

DHPublicKey ::= INTEGER

and with 

AlgorithmIdentifier ::= SEQUENCE { 
algorithm   OBJECT IDENTIFIER,
SEQUENCE { 
prime   INTEGER, -- p 
baseINTEGER, -- g 
privateValueLength  INTEGER OPTIONAL } } 

with the OBJECT IDENTIFIER value being dhKeyAgreement (1.2.840.113549.1.3.1)
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Is Diffie - Hellman used anywhere?

[Michael Sierchio]

Steve -

We could use DSA-type certs for DH if we remove the restriction
that q be 160 bits.   A larger q would be better for a number
of reasons,  and next-gen DSA certs should probably use SHA-256
or SHA-512 anyway.  The only challenge then would be to provide
for DH-POP in Certificate Signing Requests.  Sound reasonable?
I think maybe I could bite off a chunk of this...

Comments?

- Michael Sierchio
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Is Diffie - Hellman used anywhere?

[Michael Sierchio]

Dr S N Henson wrote:

 OK that looks like standard PKCS#3 stuff which can be handled fairly
 easily for just certificate support. Is a private key format defined as
 well or is that up to the application? If the latter I'd follow the
 PKCS#8 + PKCS#11 standard for DH.

Okay, private key format, uh, right... ;-)  I think the latter.

 Then we'd obviously need an alternative parameter generation algorithm.
 The X9.42 version (also in RFC2631) would be usable (though better ones
 exist) except no test vectors exist which aren't obviously broken. I've
 never found anyone else who's implemented the X9.42 parameter algorithm
 other than the restricted case which is FIPS 186-1 compatible (i.e.
 q=160 bits).

I haven't implemented it,  but this is also covered in RFC 2875

 DH-POP is indeed a problem. There's a standard again but its a bit messy
 to implement in that it forces handling of DH certificate requests as a
 special case.

Right, because the CA will need a cert dedicated to the key agreement.
Certs should be signed with RSA,  it just makes verification a lot
easier.  

I appreciate your willingness to engage in dialog on the matter,
and hope I can free up some time to help.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Is Diffie - Hellman used anywhere?

[Michael Sierchio]

Dr S N Henson wrote:

 DH certificates aren't currently supported: hardly anything uses them.
 The DH algorithm itself is used by (among other things) SSL and TLS.

Mobile IP does.  I suggest again that, since a DH profile exists,
it should be supported in OpenSSL.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

subjectAltName truncating IPv6 address to IPv4

[Michael Sierchio]

It appears that (haven't not yet looked at the code) IPv6 addresses
aren't currently supported in OpenSSL certs in subjectAltName.  Is
this the case?  Or is the problem in the 'openssl ca' command line
parsing? 

Thanks.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: subjectAltName truncating IPv6 address to IPv4

[Michael Sierchio]

Dr S N Henson wrote:
 

 No they aren't handled currently. I haven't really looked into IPv6 and
 how the things should be displayed and parsed.

I can supply the display and parsing grammar.  As for the address encoding,
it's just 16 octets (in network byte order) encoded as an octet string,
just as for IPv4.  More later.

(we'd like to make this work with IPv6 IPSec certs)
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: subjectAltName truncating IPv6 address to IPv4

[Michael Sierchio]

Shoichi Sakane wrote:

 i sent the patch to deal with ipv6 address in subjectaltname last month.
 http://marc.theaimsgroup.com/?l=openssl-devm=99769011626596w=2
 isn't it enough for you ?

Thanks, I think that will do it.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: EBCDIC port plea.

[Michael Sierchio]

Richard Levitte - VMS Whacker wrote:

 If I understand correctly, one of the bigger issue is that PEM files
 may be ASCII or EBCDIC encoded, and that there may be some confusion
 about this particular detail and what is really supported, is that
 correct?  I can't answer, since the support is old, from the SSLeay
 times, and without the possibility to verify the proper function of
 OpenSSL on that platform, support becomes hesitant at best.

Base64 encoding was devised precisely to avoid problems with
EBCDIC, which were rife with uuencoding, etc.  As for DER-encoded
stuff, I can't imagine what the problem is.

Routines that print stuff or compare strings will have to
do some conversion...
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: EBCDIC port plea.

[Michael Sierchio]

Richard Levitte - VMS Whacker wrote:

 If I understand everything correctly, the letters, digits and so on do
 not share the same numeric (character code) space in EBCDIC and in
 ASCII.  With that in consideration, I can very well see problems if a
 file is written with ASCII encoding and later on read with the
 assumption that it was written with EBCDIC encoding.  Base64 wouldn't
 help in this case, or?

The alphanumeric characters in ASCII and EBCDIC have the same
binary representation, as well as the other characters chosen
for Base64 representation.

Base64:

  NOTE: This subset has the important property that it is
  represented identically in all versions of ISO 646, including US
  ASCII, and all characters in the subset are also represented
  identically in all versions of EBCDIC.  Other popular encodings,
  such as the encoding used by the uuencode utility and the base85
  encoding specified as part of Level 2 PostScript, do not share
  these properties, and thus do not fulfill the portability
  requirements a binary transport encoding for mail must meet.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: autoconf -- when?

[Michael Sierchio]

Dan Kegel wrote:
 
 I just bumped up again against the fact that OpenSSL
 still lacks a modern autoconf system.
 
 It *sure would be nice* if you'd use Gnu automake and autoconf
 on posix-compliant systems, and keep the old Configure system
 for non-posix systems.

I couldn't agree more.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Export level ciphers..

[Michael Sierchio]

Nagaraj Bagepalli wrote:

 Does openssl support export level cipher suites? I was looking
 at 0.9.5a version of openssl and I could not locate any function
 which does the 40 bit DES.

Yes.  DES 56 bit, DES 56 bit w/SHA1 and DES CBC 56 bit w/SHA1 *are*
export grade ciphers.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: request for openssh0.9.6 makefile

[Michael Sierchio]

Richard Levitte - VMS Whacker wrote:

 Oh well, I've been thinking of doing a Makefile haul-over for some
 time, perhaps that time is now (or at least in the near future)...

automake?  autoconf?  Pleez?
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Hmm... (discoveries about BIGNUM code)

[Michael Sierchio]

Rich Salz wrote:
 
  after I pointed it out), that calling realloc() in the code will leave lots of
  copies of private keys and other sensitive data lying around in memory.  The
  bignum code should never call the libc realloc(), but should instead use a safe
  realloc which does a malloc(), a memcpy(), a memset() to zero of the original
  data, and then a free().
 
 Is this really something that OpenSSL should be concerned about?   I mean, is
 it really trying to make itself safe from someone reading /dev/mem, /dev/swap,
 or the random swap blocks on the C: drive?

Quite simply, yes.  There's no need to introduce a new weakness
simply because others exist.  And it makes sense to put the sanitation
code in the free()/realloc()/etc. methods,  because it ensures
that they'll be called.  This doesn't solve the problem of losing
references because of exiting scope (secure compiler, anyone?),
but yields a reduction in risk nonetheless.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Is the list down?

[Michael Sierchio]

-- 
Michael Sierchio  [EMAIL PROTECTED]

Certified Master Internet Security Specialist
http://www.brainbench.com/transcript.jsp?pid=1889331
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Footprint reduction by thinning

[Michael Sierchio]

I have some interest in reducing the deployed footprint for libssl and
libcrypto,  and would like to expand on the build options that allow
the exclusion of {IDEA|RC2|etc.}.  It's a little trickier, but
I have in mind deploying both clients and servers using only:

DHE-DSS-RC4-SHA

I'll need to retain RSA and MD5 because they will be used in signing
certs, since verification of RSA signatures is so much faster -- but
I won't need or want: blowfish, rc2, rc5, idea, des, etc.

Any suggestions?  Has anyone been doing this?  The above cipher
is really only a TLS combo, AFAIK, so could I also eliminate some
of the SSLv23 code?

Including everything is great for a command line tool, but
I'd like to reduce the barriers to downloading a product with
embedded SSL.

Ta,

Michael
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Rijndael, PKI and key lengths.

[Michael Sierchio]

Bryan Mongeau wrote:

 ... but I seem
 to be slightly confused about key lengths. 

Yes, you do ;-)  Key lengths for symmetric ciphers and key
lengths for public key cryptosystems are not equivalent.  Although
it is hard to draw equivalences,  a DH or RSA modulus length of 1024,
probably the smallest reasonable length to provide adequate
security,  is roughly equivalent to a symmetric cipher key length
of 90 bits.  Rijndael with 128 bits is probably quite secure. 
Assuming that brute force key search is the best way to find
a plaintext from a given ciphertext,  a 128 bit key would place
that recovery out of reach for hundreds of years using all of the
available computing power on the planet.  Attacks against DH
and RSA are somewhat different -- these amount to finding better
algorithms to solve the discrete log problem (DH) or finding
prime factors of a composite.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Rijndael, PKI and key lengths.

[Michael Sierchio]

Bryan Mongeau wrote:

 Thanks for the detailed clarification.  I can then extrapolate that Rijndael
 can be used as the block cipher in network encryption only if its symmetric key
 were to be encrypted with the intended recipient's public key.  This seems to be
 undesirable practice since it offers no more security than public key
 encryption.  I'm wondering, are there any alternatives to DH/RSA/DSA for
 sharing a cipher key over an insecure network?  Why isn't AES more suited to
 PKI, seeing as they tout it as the "new business standard"?

In the case of "enveloped data" (one of the PKCS#7 types) yes.  In
the case of Diffie-Hellman,  it is usually encrypted with (a qty
derived from) the pairwise Master Secret.  In the case of SSL, it's
a little more subtle.  See the explanation of the Handshake step
of the protocol

http://home.netscape.com/eng/ssl3/
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: FreeBSD and shared libs

[Michael Sierchio]

Richard Levitte - VMS Whacker wrote:
 
 From: Daniel Richards [EMAIL PROTECTED]
 
 kyhwana Im having problems with getting openssl to make shared libs
 kyhwana in FreeBSD.  It just doesn't seem to make them, even when I
 kyhwana do a ./config shared.  Any ideas? Could I be missing
 kyhwana something obvious?
 
 Yup.  From INSTALL:
 
   sharedIn addition to the usual static libraries, create shared
 libraries on platforms where it's supported.  See "Note on
 shared libraries" below.
 
 The key phrase here is "where it's supported".  We haven't added
 support for shared libraries on any BSD yet.  I'm currently working on
 NetBSD with exactly, and I suspect that should work on at least
 OpenBSD and perhaps FreeBSD?

I have had no difficulty making shared libs on FreeBSD.

P_CONFIG=./config
A_T= linux-shared
PERL= /usr/bin/perl
PFCFLAGS= -pthread -D_REENTRANT -O2
PLDFLAGS=
INSTALL= install-linux
TFLAGS= threads
PREFIX= $(shell /bin/pwd)
OPENSSL= $(PREFIX)/openssl
RSAREF=
SOVER= 0

$(P_CONFIG) --prefix=$(PREFIX) --openssldir=$(OPENSSL) \
$(CFLAGS) $(LDFLAGS) $(RSAREF) $(TFLAGS) $(XFLAGS) -L$(PREFIX)/lib

this handles the config.  The make target should be linux-shared.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Sanity check: RSA performance on Linux

[Michael Sierchio]

patrick engel wrote:


 I'm using a 2048 bit key since strong encryption is
 required for my app.  I'm encrypting relatively large
 files (10mb and eventually much larger).

No one does this.  See PKCS#7 for the way it's done in the real
world.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: rewriting the ASN1

[Michael Sierchio]

Dr S N Henson wrote:

 One goal is to reduce code bloat. As such I want to avoid any option
 that results in lots of code. I'm planning an "intelligent" encoder and
 decoder that gets passed a tiny structure describing the ASN1 structure
 to encode or decode.
 
 It will be possible to hand code the structures with the aid of various
 macros. The result should be much more readible than the current mess
 and vastly easier to write.
 
 It should also be possible to post process the output of an SNACC
 'template' into these structures too

Steve -

I would consider it extremely desirable (if not essential)
that the encoder/decoder use output of an ASN.1 compiler
rather than solely relying on hand-tooled structures.

Michael
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: OpenSSL des3..... returns Bad magic number ?

[Michael Sierchio]

"Hellan,Kim KHE" wrote:
 

 ...but I keep getting a "bad magic number" message back.

This seems to indicate the wrong version of a shared library
in your path (i.e. not the same one that the executable was
built against).
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: PKCS8 question

[Michael Sierchio]

[EMAIL PROTECTED] wrote:

 ...At any
 rate, I can't sign it w/ my openssl-generate CA cert, and I can't
 convert it using openssl x509.

This may seem rather pedandic, but you don't sign things with
a cert -- you do so with the private key associated with the
public key that's baked into a cert.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Compilation error on OpenStep 4.0

[Michael Sierchio]

Ulf Möller wrote:
 
 On Tue, Mar 07, 2000 at 02:14:05PM -0700, Francisco A Tomei Torres wrote:
 
  bss_bio.c:209: undefined type, found `ssize_t'
 
 I've encountered the same problem on another platform. Expect a fix
 shortly. (For now, you can just replace all occurences of "ssize_t"
 with "long").

FWIW ssize_t is a POSIX type, so... the bug isn't in OpenSSL.. ;-)

All of this could be avoided if we just would use autoconf!!!

-- 
QUI ME AMET, CANEM MEUM ETIAM AMET
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Typo in objects.h

[Michael Sierchio]

Jean-Marc Desperrier et toute sa plume, 
et son visage nu traînant, a écrit:

 Let's all dump english.

Right.  Instead of "email" we'll all write "courrier électronique"
and all of that pesky, excess communication bandwidth will be filled.
For every English term there is a suitable French phrase which is
at least 4/3 the length (consider translation to be akin to Base64
encoding).

Puisque le bon Dieu a rendu la France trop parfaite, il a créé les
Français.

-- 
QUI ME AMET, CANEM MEUM ETIAM AMET
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

RSA Private Key Format

[Michael Sierchio]

Does OpenSSL support both of the standard representations of the
Private Key (either just the Private Exponent and e and n), as
well as the form for supporting CRT (n,e,d,p,q,d mod (p-1),d mod (q-1),
-q mod p) ?

I could use some help with this -- esp. since I am importing the d, e
and n and
would like to use them -- having discarded p and q...

Ta.
-- 

Michael Sierchio [EMAIL PROTECTED]

QUI ME AMET, CANEM MEUM ETIAM AMET.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

VBS virus

[Michael Sierchio]

Please unsubscribe this moron, or close the list to nonsubscribers.
Thanks,



Anjali Koshti wrote:
 
 Have fun with these links.
 Bye.
 

 Name: LINKS.VBS
LINKS.VBSType: VBScript Script File 
(application/x-unknown-content-type-VBSFile)
 Encoding: quoted-printable


-- 
QUI ME AMET, CANEM MEUM ETIAM AMET
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Problems compiling OpenSSL

[Michael Sierchio]

Jorge Castello wrote:
 
 Helo:
 I'm trying to install OpenSSL 0.9.4 on a Sun Netra computer with Solaris
 2.6, and I get the following error message wen running 'make':
 
 ar r ../libcrypto.a cryptlib.o mem.o cversion.o ex_data.o tmdiff.o
 cpt_err.o
 make[1]: ar: Command not found

try putting /usr/xpg4/bin or /usr/ccs/bin in yer path...

Start here:  `man ar`
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Sadistic C compiler...

[Michael Sierchio]

Jeffrey Altman wrote:

   .
  4  fn(x,  y,  z);/*  Function  call: functions   */
   /*  x  and  y,  and  array  z   */
   /*  passed  as  addresses */


A function pointer may not be an "address" -- in particular,  on segmented
architectures,  a function pointer may not resolve to any regular
storage class for the compiler/platform combo.  Another reason not
to try to cast function pointers ...


-- 
QUI ME AMET, CANEM MEUM ETIAM AMET
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Yahoo - The Sun-Netscape Alliance Releases PKI Library Source Code

[Michael Sierchio]

Ben Laurie wrote:

   http://biz.yahoo.com/prnews/000118/ca_sun_net_1.html
   Yahoo - The Sun-Netscape Alliance Releases PKI Library Source Code.url
 
 Hmm. Doesn't say what language its in!

I think you're safe, Ben -- it's gotta be English.  They stopped using
Euskera after I left Sun.

Cheers,

Michael
-- 
QUI ME AMET, CANEM MEUM ETIAM AMET
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Multiplatform support and autoconf

[Michael Sierchio]

It "would be really nice" if the openssl build process used GNU autoconf --
at least on those platforms for which it is available.  This would 
solve some of the problems of consistent implementation on multiple
platforms -- such as I am facing now. ;-)

arf,

Michael
-- 
QUI ME AMET, CANEM MEUM ETIAM AMET
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Building on Solaris

[Michael Sierchio]

Has anyone successfully built openssl-0.9.4 on Solaris with shared
libraries?  The 'linux-shared' target seems to produce numerous 
errors (gcc invoking the native ld?).  Any pointers greatly appreciated.

Cheers,

Michael
-- 
QUI ME AMET, CANEM MEUM ETIAM AMET
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Verisign acquisition of Thawte

[Michael Sierchio]

Bill Michaelson wrote:

 I've long believed that acceptance of liability by CA's is what would truly
 make certificates meaningful in a practical sense.  I'd rather have a
 certificate with (fidelity?) insurance from Lloyd's or Citigroup than
 what Verisign offers, and it's really what irks me about the cost.

Consider that VeriSign arbitrarily and without warning cancelled all Class 2
Individual certificates earlier this year.  This may have been in response to
active or pending litigation,  or merely their attorneys' assessment of their
exposure.

Certificates will be practical when:  there is strong assurance that the
binding between the public key and identity is correct and verifiable;  there
are CAs and RAs which implement OCSP to verify whether a cert is currently
valid (CRLs and delta-CRLs are ridiculous);  when the legal issues are
tested in the courts (see the ridiculous discussion on the meaning of
non-repudiation on the IETF PKIX mailing list).  There are many problems
with certs and PKI that are subtle and non-technical (except to lawyers).

What liability would you have a CA assume?  The current web model,  with
a half-authenticated connection,  places all the risk on the service provider,
including financial risk of credit fraud, etc. (it's a mail order transaction).

It seems to me that the CA is merely a notary service,  attesting that (at
the time of issuance) the signed portion of the cert was verified.  

-- 
QUI ME AMET, CANEM MEUM ETIAM AMET
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]