Re: Format and standard for CSR

[Michael Sierchio]

I don't see the point in DER encoding for a CSR – The RA and CA decide the
composition of the cert, based on the rules and CPA that they follow, and
of course any cert issued will be in DER format, and may include reordering
or modified/expanded extensions and key use restrictions.  A CSR is
basically an assertion that includes pubkey, proof of possession of the
private key, and any request elements required by policy.  It's a one-time
document that needs to be validated precisely once.


On Wed, Aug 28, 2019 at 6:49 AM Robert Moskowitz 
wrote:

> I am writing an Internet Draft that will include transmission of a CSR,
> so I need to reference the proper source.  No more sloppy, "well it
> works...".
>
> Some digging said it is in PKCS#10 - CSR.  But I did not stop with that.
>
> A bit more googling lead me to RFC 4211...
>
> When I create a CSR with:
>
> openssl req -config openssl-intermediate.cnf\
> -key ./private/client.key.pem \
> -subj "$DN" -new -out ./csr/client.csr.pem
>
> What format is this?  Are there better, more concise formats (e.g. DER?)
> for transmission over constrained networks?
>
> I can dump it with
>
> openssl req -text -noout -verify -in ./csr/client.csr.pem
>
> But that does not really tell me the format, only what is in the cert.
>
> Thanks
>
>

-- 

"Well," Brahmā said, "even after ten thousand explanations, a fool is no
wiser, but an intelligent person requires only two thousand five hundred."

- The Mahābhārata

Re: [openssl-users] RFC5077 ticket construction help

[Michael Sierchio]

On Wed, Mar 28, 2018 at 9:44 AM, Viktor Dukhovni  wrote:

It would more sense for C to issue short-term client certificates.
> Session tickets are for session resumption.  In particular they
> can't authenticate the server to the client, so you still need
> an initial handshake for that.
>
> To do GSSAPI with TLS, do TLS on the outside (client authenticates
> the server and establishes an secure channel), and then GSSAPI
> with channel binding (server authenticates the client as being the
> party at the other end of the channel).
>
>
It would make more sense, but you're changing the problem definition.
Needham-Schroeder is intended to be used over an insecure network.


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

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

Re: [openssl-users] RFC5077 ticket construction help

[Michael Sierchio]

Since there exists a reference implementation, and the source code is
available, why not start there?  The symmetric key protocol is the basis of
Kerberos.

- M

On Wed, Mar 28, 2018 at 9:26 AM, Henderson, Karl via openssl-users <
openssl-users@openssl.org> wrote:

> Need some help with RFC5077 ticket construction. I’d like to implement a
> type of Needham-Schroeder protocol where:
>
>
>
>- A wants to talk to B
>- A and B have a relationship with C
>- C constructs an RFC5077 ticket and gives it to A so that A can
>contact B
>
>
>
> Are there any good examples of how to do this?
>
>
>
> The problem I think I’m having the most difficulty with is understanding
> what I need to put into the encrypted_state portion of the session ticket.
>
>
>
> Thanks,
>
> Karl
>
>
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
>


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

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

Re: [openssl-users] How to form a proper hash after writing something into SSL handshake.

[Michael Sierchio]

Comic Sans. Need I say more?

On Tue, Dec 26, 2017 at 4:53 AM, Sai Teja Chowdary <
asteja.chowdary.ec...@itbhu.ac.in> wrote:

>
>
> Hi,
>
>
>
> Happy Holidays everyone.
>
>
>
> I want to send client certificate, client key exchange and client verify
> in a single handshake message which appears as multiple handshake messages
> in a single record. But to sent the client verify I need to first make a
> hash of previous messages(client certificate and client key exchange) to
> create the signature.
>
>
>
> Can anyone help me to find the function in OpenSSL 1.1.1-dev  xx XXX 
> (or right procedure that needs to be done before creating a certificate
> verify message)that can do a proper transcript(digest or hash not clear). I
> tried using *ssl3_finish_mac() *on the message containing client
> certificate and client key exchange and then tried to generate the
> signature in certificate verify message.
>
> But it is giving me a digest error. I am new to the mailing list want a
> bit of help to proceed forward stuck here. Please reply in case if anything
> is not clear.
>
>
>
> Here is a code snippet, how I am forming the data containing all client
> certificate , client key exchange and certificate verify messages inside
> write_state_machine().
>
>
>
> if(WPACKET_init(, s->init_buf)){
>
> //Client certificate formation
>
>  if(!ssl_set_handshake_header(s,,mt) || confunc != NULL
> && !confunc(s,) || !ssl_close_construct_packet(s,,mt)){
>
>   printf("PROBLEM\n");
>
> }
>
>  transition(s);  //transition to next state i.e client key
> exchange
>
>
>
>  get_construct_message_f(s, , , );
>
> //client key exchange formation
>
>  if(!ssl_set_handshake_header(s,,mt) || confunc != NULL
> && !confunc(s,) || !ssl_close_construct_packet(s,,mt)){
>
>printf("AGAIN A PROBLEMO\n");
>
> }
>
>
>
> //ssl3_finish_mac(s, >init_buf->data[s->init_off], s->init_num);
>
>  st->write_state_work = post_work(s, st->write_state_work);
>
>  transition(s);  // transition to next state i.e  certificate
> verify
>
>
>
>  get_construct_message_f(s, , , );
>
> //certificate verify message formation.
>
>  if(!ssl_set_handshake_header(s,,mt) || confunc != NULL
> && !confunc(s,) ||
> !ssl_close_construct_packet(s,,mt)){
>
>printf("AGAIN A PROBLEMO\n");
>
> }
>
>  WPACKET_finish();
>
>
>
>
>
> Please take a look at it, appreciate every bit of help.
>
>
>
> Regards,
>
> Saiteja
>
>
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
>


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

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

Re: [openssl-users] Rejecting SHA-1 certificates

[Michael Sierchio]

On Mon, Jul 10, 2017 at 10:22 AM, Viktor Dukhovni <
openssl-us...@dukhovni.org> wrote:

>
> > On Jul 10, 2017, at 1:12 PM, Niklas Keller  wrote:
> >
> > It's very well worth the effort, otherwise there's a security issue,
> because certificates can be forged.
>
> Collision attacks don't directly lead to certificate forgery.  There are
> no known 2nd-preimage attacks on SHA-1.


I'm pretty sure, but are you saying you would rather wait for a
demonstration of the weakness being turned into a practical attack?

Second pre-image attacks against reduced SHA-1 have been demonstrated. It's
only a matter of time before second pre-image resistance for full SHA-1 is
dead and buried.

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

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

Re: [openssl-users] Query regarding MSG_NOSIGNAL with SSL_Write

[Michael Sierchio]

On Tue, May 2, 2017 at 8:27 AM, Michael Wojcik <
michael.woj...@microfocus.com

> wrote:

It may be worth noting that nearly all well-written UNIX applications
> should set the disposition of SIGPIPE to SIG_IGN. SIGPIPE is a hack. It
> exists only to terminate poorly-written programs that could otherwise block
> a pipeline. See Bach, *The Design of the UNIX Operating System*; if
> memory serves, Bach quotes Dennis Ritchie on this point. SIGPIPE was
> introduced because some poorly-written programs did not check the return
> code from write.[1]
>
...

This is excellent advice. In principle, I am in complete agreement. We
should not write code that depends on this artifact. We should treat it as
deprecated.

However ... ;-)

It's probably also true that there is a lot of code that depends on it.
True to form for "deprecated"

- M

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

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

Re: [openssl-users] dates, times, durations in next release (commands)

[Michael Sierchio]

On Tue, Sep 6, 2016 at 10:40 AM, Jakob Bohm  wrote:
...

> Another related (long standing) issue is the inability to
> state an "as of" date to the various commands and APIs that
> validate signatures, certificates etc.  Both past and future
> dates can be needed in various use cases.

...

That would be really useful. An expired or revoked certificate may still be
used to verify a signature generated at a time when the certificate was
valid.

-- 
"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-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] openSSL and SLOTH attack

[Michael Sierchio]

"Since the HMAC is only 96 bits long, even a generic collision requires
only about 248 HMAC computations"

But a sequence/call-flow diagram is on the page Sandeep referenced:
http://www.mitls.org/pages/attacks/SLOTH

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

Re: [openssl-users] openSSL and SLOTH attack

[Michael Sierchio]

2^48. Which is larger than 248, which was a cut-and-paste error. ;-)

On Fri, Jan 8, 2016 at 11:00 AM, Michael Sierchio <ku...@tenebras.com>
wrote:

> "Since the HMAC is only 96 bits long, even a generic collision requires
> only about 248 HMAC computations"
>
> But a sequence/call-flow diagram is on the page Sandeep referenced:
> http://www.mitls.org/pages/attacks/SLOTH
>
> - M
>
>
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] pkcs12 is no encryption possible for certs?

[Michael Sierchio]

On Fri, Feb 13, 2015 at 11:33 AM, Sean Leonard dev+open...@seantek.com wrote:
 Using the openssl pkcs12 -export command, is it possible to specify a
 -certpbe value that does not do encryption? Perhaps you only want
 integrity protection--you don't care whether the certificates are shrouded.
 The PKCS #12 standard seems to imply that certBags can be used as-is;
 however, all examples of PKCS #12 files that I have seen encrypt the
 certificates.

 Will other common crypto stacks be able to process such a PKCS #12 file
 (that does not encrypt the certificates)?

Whenever I hear someone talking about encrypting a certificate, I
conclude that they are horribly confused. A cert is signed, over the
entire contents, so integrity is reducible to the cryptographic
algorithms employed. A cert is not a secret, does not contain secrets,
etc.

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

Re: [openssl-users] pkcs12 is no encryption possible for certs?

[Michael Sierchio]

Yes, I am sure that some folks find known plaintext in an encrypted object
to be helpful.

[apologies for top-posting... dumb smart phone]

- M
On Feb 13, 2015 1:21 PM, Viktor Dukhovni openssl-us...@dukhovni.org
wrote:

 On Fri, Feb 13, 2015 at 12:02:06PM -0800, Michael Sierchio wrote:

  Whenever I hear someone talking about encrypting a certificate, I
  conclude that they are horribly confused. A cert is signed, over the
  entire contents, so integrity is reducible to the cryptographic
  algorithms employed. A cert is not a secret, does not contain secrets,
  etc.

 And yet, PKCS#12 objects are encrypted, and include certificates.

 --
 Viktor.
 ___
 openssl-users mailing list
 To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: Browsers do not import chained certificate.

[Michael Sierchio]

On Wed, Oct 8, 2014 at 11:17 PM, dE de.tec...@gmail.com wrote:
 Hi!

 I'm trying to make a certificate chain using the following commands --

 openssl genpkey -out issuer.key -algorithm rsa
 openssl genpkey -out intermediate.key -algorithm rsa
 openssl req -new -key issuer.key -out issuer.csr
 openssl req -new -key intermediate.key -out intermediate.csr
 openssl x509 -req -days 365 -in issuer.csr -signkey issuer.key -out
 issuer.pem
 openssl x509 -req -days 360 -in intermediate.csr -CA issuer.pem -CAkey
 issuer.key -CAcreateserial -out intermediate.pem

 After importing issuer.key to chrome/FF when I try to import
 intermediate.pem, I get errors. Namely --

 This is not a certificate authority certificate, so it can't be imported
 into the certificate authority list. from FF and intermediate: Not a
 Certification Authority from Chrome.

 Other intermediate certificates as provided by websites work fine.

Probably because they have the proper extensions that designate them
as intermediate CAs.

- M
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: best practice for creating a CA cert?

[Michael Sierchio]

On Sun, Sep 28, 2014 at 11:59 PM, Jason Haar jason_h...@trimble.com wrote:

 ...
 If I just click through the defaults of openssl ca, I'd probably end
 up with a 2048bit RSA, SHA-2 (256) cert. So my question is, should I
 future proof that by making it 4096bit and maybe SHA-2 (512)? (ie I want
 the CA to be viable for 10 years, not 5 years). What is the performance
 impact of increasing these values of the CA cert itself? I'd expect to
 still only sign 2048-bit, SHA-256 server/client certs - but is there a
 real performance downside to making the CA cert itself stronger? I don't
 care if the CA takes 30 seconds longer to sign a cert - but I'd really
 care if it made a web browser hang when talking to the resultant server
 cert ;-)

There are many places where  a PKI breaks - hash collisions are far
down the list.

Most internal CA implementations offer no more effective security or
trust than just using self-signed certs - the objective seeming to be
to make browsers not complain about the SSL connection. Without
subsidiary CAs, good discipline about their use, a CRL distribution
point baked into certs (or OCSP), you can only verify that a cert was
valid when it was signed, but have no way of dealing with private key
compromise, etc. which happens all the time.

Spend some time thinking about revocation, cert lifespan, etc.if you
want to make a CA stronger.

- M
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: cannot read PEM key file - no start line

[Michael Sierchio]

On Sun, Sep 7, 2014 at 10:26 PM, Liz Fall f...@sbcglobal.net wrote:

 I am getting the following with my client cert when trying to connect to an 
 SSL-enabled MongoDB:

 2014-09-03T13:37:56.881-0500 ERROR: cannot read PEM key file: 
 /users/apps/tstlrn/u019807/DTCD9C3B2F42757.ent.wfb.bank.corp_mongo_wells.pem 
 error:0906D06C:PEM routines:PEM_read_bio:no start line

 The cert file is the following:

Cert file or key file? The error indicates that the client can't find
the private key.

 free from viruses and malware because avast! Antivirus protection is active.

Thanks for that amusing bit of insight.

- M
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: The no-stdio and NO_FP_API options

[Michael Sierchio]

On Wed, Sep 3, 2014 at 4:21 PM, Jens Maus m...@jens-maus.de wrote:

 Am 03.09.2014 um 21:33 schrieb Salz, Rich rs...@akamai.com:

  +1 for keeping the features (I use AmiSSL ;) )
 
  It doesn’t build.  Unless that is addressed, it is highly likely that I
 will remove it from the tree after 1.0.2

 Well, then why are you asking for opinions in first place if your decision
 is already made. All I can say is that AmiSSL perfectly builds without an
 file pointer based functions and without stdio. I can of course prepare a
 diff for you but this diff will then include other amiga related
 modifications as well.


Please - show, don't tell. Diffs and some details of the build environment
would be helpful.

-  M

Re: help with error

[Michael Sierchio]

My Windoze knowledge is hazy, and from the distant past, but if you're
running this in a CMD window, you may simply need to increase the
available memory from the default for that process.

- M

On Thu, Jul 3, 2014 at 11:43 AM, Steven Kinney
steven.kin...@ers.state.tx.us wrote:
 No. Running on my Dell laptop.


 Sent on the new Sprint Network from my Samsung Galaxy S®4.


  Original message 
 From: Jakob Bohm
 Date:07/03/2014 1:23 PM (GMT-06:00)
 To: openssl-users@openssl.org
 Subject: Re: help with error

 On 7/3/2014 5:50 PM, Steven Kinney wrote:
 I enter the following command, as instructed by Cisco:

 req -new -config c:\openssl\share\openssl.cnf -newkey rsa:1024 -nodes
 -keyout mykey.pem -out myreq.pem

 And I get the following error:

 Please enter the following 'extra' attributes

 to be sent with your certificate request

 A challenge password []:tester

 Error adding attribute

 7684:error:0D0BA041:asn1 encoding routines:ASN1_STRING_set:malloc
 failure:./cryp

 to/asn1/asn1_lib.c:381:

 7684:error:0B08A041:x509 certificate
 routines:X509_ATTRIBUTE_set1_data:malloc fa

 ilure:./crypto/x509/x509_att.c:317:

 problems making Certificate Request

 error in req

 Any help would be appreciated.


 I think the important part is malloc failure, in which case you
 simply don't have enough free ram to run the command.

 Are you by any chance running the command on a heavily loaded
 router?


 Enjoy

 Jakob
 --
 Jakob Bohm, CIO, Partner, WiseMo A/S.  http://www.wisemo.com
 Transformervej 29, 2730 Herlev, Denmark.  Direct +45 31 13 16 10
 This public discussion message is non-binding and may contain errors.
 WiseMo - Remote Service Management for PCs, Phones and Embedded
 __
 OpenSSL Project http://www.openssl.org
 User Support Mailing Listopenssl-users@openssl.org
 Automated List Manager   majord...@openssl.org
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: Improving structure and governance

[Michael Sierchio]

I've been thinking that the OpenSSL Foundation really needs to do better
than simply being open to individual funders.  A lot of companies use the
libraries, and asking for some proper do-re-mi is completely kosher.

More on this later, I'm in Florida this weekend (feel sorry for me).

- M


On Fri, Apr 25, 2014 at 6:36 AM, Salz, Rich rs...@akamai.com wrote:

 While we're still waiting to hear from the core team about changes, I
 might as well add to the noise and throw this out there.



 Perhaps openssl should become an Apache project? Keep the foundation for
 financial reasons, but use their infrastructure and such.  Or perhaps
 consider adopting a large portion of their rules.



 /r$



 --

 Principal Security Engineer

 Akamai Technologies, Cambridge, MA

 IM: rs...@jabber.me; Twitter: RichSalz

Re: using TRNG via /dev/random

[Michael Sierchio]

On Mon, Sep 23, 2013 at 12:59 PM,  starlight.201...@binnacle.cx wrote:
 At 20:27 9/23/2013 +0200, Richard Könning wrote:
/dev/random is a PRNG which blocks when the (crude)
entropy estimation  of the entropy pool falls below a
limit. Besides this there are  afaik no big
differences between /dev/random and /dev/urandom.

 In the sense that all TRNG outputs are run
 through various algorithms that mix and
 whiten the data to assure uniform statistical
 distribution, all TRNGs could be called
 PRNGs.  However the crucial difference is
 that TRNG post-filter output is irreproducible
 where a pseudo random number generator
 will predictably generate identical streams
 of output given the same seed

First, whenever someone talks about true random numbers, I assume
they are kidding - I know of no cryptographers who use that term. It's
a meaningless phrase.  Cryptographically useful random number
generators possess the desired characteristics - no detectable bias
in the bitstream, passing all the usual FIPS tests, etc., as well as
forward and backward secrecy, etc. and make use of all available
sources of entropy.  Unless you're talking about a naive
implementation of a LFSR or somesuch, PRNGs don't have a single seed.

I'll repeat myself - the fact that the /dev/random implementation
you're using blocks is a serious design flaw.  Secondly, presuming
that the current process (openssl-based) is permitted to perform a
blocking read on a constrained system resource is similarly misguided
- there may be other processes that want random bits, too.

- M
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: using TRNG via /dev/random

[Michael Sierchio]

On Sat, Sep 21, 2013 at 2:09 PM, David Lawless
david_lawl...@flumedata.com wrote:
 ...
 Next I did this:

cd /dev
mv urandom urandom.hold
mknod urandom c 1 8

 Which causes /dev/urandom to make use of
 the /dev/random driver in the kernel.

 The above sort-of works.  Some of the new
 'openssl' connections to servers on this system
 succeed.  However most return cannot renegotiate
 error.

 My guess is that 'openssl' is either not obtaining
 enough random bytes on the first try from /dev/random
 or is issuing a non-blocking read() and is told
 to try-again due to transient shortages of
 entropy.

I assume that this is on a Linux distro?  The design of the standard
Linux /dev/random is old.  It was brilliant at the time (I think Ted
T'so is responsible for the brilliance), but has some characteristics
that are less than useful in this application.  You'd do better to use
something like the FreeBSD /dev/random, which is based on Yarrow.

https://www.usenix.org/legacy/events/bsdcon/full_papers/murray/murray_html/

http://svnweb.freebsd.org/base/release/9.1.0/sys/dev/random/

If there is a hardware RBG on the computer, and /dev/crypto exists, it
can mix in bits from that. (Most hardware RBGs have a max bit rate of
16kbps, which is not adequate for a busy server with need for a lot of
random material)

Think of how much better this is than when we had to use the noisy low
bits of the audio input combined with von Neumann decorrelation. ;-)

Cheers.

- M
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: using TRNG via /dev/random

[Michael Sierchio]

On Sun, Sep 22, 2013 at 10:00 AM,  starlight.201...@binnacle.cx wrote:

 Not interested in any PRNG.

/dev/random is a PRNG.  As I pointed out, True RBGs don't produce
enough material.  The problem is the fact that /dev/random blocks.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: Encumbered EC crypto algorithms in openssl?

[Michael Sierchio]

On Fri, Aug 16, 2013 at 10:40 PM, Nico Williams n...@cryptonector.comwrote:

 If only we could agree to use DJB's Curve25519...


+1

Re: Validating a certificate which is expired

[Michael Sierchio]

On Wed, Jun 19, 2013 at 1:34 PM, Dave Thompson dthomp...@prinpay.com wrote:
From: owner-openssl-us...@openssl.org On Behalf Of Bob Bell (rtbell)
Sent: Wednesday, 19 June, 2013 15:01

I have a situation where I need to determine the validity of a certificate
in all other aspects even though it has expired. In other words, the
signatures are all valid and the contents untampered, but the notAfter
date is less than current date. If I run the certificate verify process

 What about revocation? CA's aren't required to maintain and provide
 revocation status for certs that have expired. But see below.

against that certificate, will it tell me if there are higher severity
 errors
(e.g. issuer signature invalid) rather than checking the validity period
and finding the problem? I guess another way of asking the question is
If I get the error 10 X509_V_ERR_CERT_HAS_EXPIRED: certificate has
 expired
does that imply that everything else is OK?

 UTSL but even if so I see no guarantee it won't change in future.

 What you can do is verify using a specific past time instead of now:
 commandline verify -attime or X509_VERIFY_PARAM_SET_TIME .

 But the CRL logic is pretty complicated and I'm not certain
 if it will find just the CRL(s) for the past time without help
 -- but I'm sure it could do so only if you already have them,
 since you won't be able to request them from the CA.

This is not a rare pattern - e.g., validation of a signature after the
signer's cert has expired.  The problem is that, without exhaustive
CRL access, it's impossible to know if the certificate is not revoked
for some reason that would invalidate the signature (loss or
compromise of private key, etc.).

- M
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: FIPS Capable Ciphers List

[Michael Sierchio]

On Wed, May 15, 2013 at 8:26 AM, Viktor Dukhovni openssl-us...@dukhovni.org
 wrote:

OpenSSL cipherlists are not for novices.


Like everything else about an old API that grew organically, it has too
much surface area.  It's unreasonable to rely on expert performance to
prevent errors - it should be hard to make mistakes when the consequences
are great.  That's a reliable principle of good design.

- M

Re: Does CSR need to be signed with matching private key?

[Michael Sierchio]

On Mon, Mar 4, 2013 at 9:33 PM, Steven Funasaki
thegreatste...@gmail.com wrote:

 Does the CSR need to be signed with the matching private key for the CA to
 validate it?

Of course.  That demonstrates proof of possession of the private key.
Otherwise there is no binding of an entity to a keypair, and no cert
can have any validity whatsoever.  What precisely do you think a
certificate is?

- M
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: OpenSSL: RC4 and IDEA algorithms

[Michael Sierchio]

RC4 is not patented - RC4 is a Trademark of RSA Security.

On Wed, Jan 23, 2013 at 8:36 AM, sarju tambe sarjuta...@gmail.com wrote:
 In OpenSSL(README File, openssl version-0.98x), there are 4 patented
 algorithms RC5, RC4, IDEA, Camellia out of which RC5 and Camellia are
 disabled in Configure file.

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: genrsa question how secure is the random creation

[Michael Sierchio]

On Tue, Dec 11, 2012 at 8:06 PM, Michael Sierchio ku...@tenebras.com wrote:

 - Select an interval near the desired size

[ 2^1023 + 1^1022 + 1 , 2^1024 - 1 ]

 - Sieve out composites divisible by small primes
 - Select two probable primes such that (p - q) is reasonably large
 (2^100 or so) to defeat the difference-of-squares method

Before testing for primality, make sure that p mod e != 1, where e is
the public exponent

 - Perform enough primality tests to convince yourself they're prime ;-)
 - other common criteria aren't really helpful - e.g. strong primes
 (they were never necessary for RSA), restrictions on p-1 and q-1
 (Elliptic Curve Method factoring makes those obsolete)
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: genrsa question how secure is the random creation

[Michael Sierchio]

On Tue, Dec 11, 2012 at 3:27 PM, redpath redp...@us.ibm.com wrote:
 When using this command

 openssl genrsa -out test.pem  2048

 an RSA pair is created. Its not so much I want to know how a pair is
 randomly selected
 but how secure is that random selection. Random number generators are a
 series
 and this selection could be followed for brute force deciphering.

 Random number generators are a series

This is not invariably true, and in any case most depend for their
security on the availability of a small amount of entropy for seeding
- /dev/random is suitable, esp. on BSD systems that use a Yarrow-based
mixer.

There are side channel attacks against RSA key generation, but
guessing random numbers isn't one of them.

The real question is how the probable primes are selected.

- Select an interval near the desired size
- Sieve out composites divisible by small primes
- Select two probable primes such that (p - q) is reasonably large
(2^100 or so) to defeat the difference-of-squares method
- Perform enough primality tests to convince yourself they're prime ;-)
- other common criteria aren't really helpful - e.g. strong primes
(they were never necessary for RSA), restrictions on p-1 and q-1
(Elliptic Curve Method factoring makes those obsolete)

I can't answer the question about genrsa, I haven't looked at the code
in a very long time.  But I observe that openssl is maintained by a
lot of smart folks who are always responsive to reported exploits and
vulnerabilities.

Maybe Dr. S.H. will chime in...

- M
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: add hash signature as part of the stream on which this hash is based on

[Michael Sierchio]

On Mon, Nov 19, 2012 at 9:24 AM, lists li...@rustichelli.net wrote:

 By its nature, a hash completely changes if just a bit of the original
 content is modified

By design, a cryptographic hash function (on average) changes half the
output bits when a single bit in the input is inverted.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: CN in SubjectAltName necessary ?

[Michael Sierchio]

The semantics of subjectAltName depend on use.  For example

http://tools.ietf.org/html/rfc4945


On Tue, Oct 23, 2012 at 1:57 AM, Thomas alth...@gmx.net wrote:
 Hey there,

 for openssl, is it necessary to include the CN in the subjectAltName field
 if the latter one is present at all ?

 I would expect the answer to be 'no' because I would expect the CN and
 subjectAltName field to be in a 'or' relation - so either one to match would
 be sufficient. Openssl (1.0.0j) complains if the subjectAltName extension is
 set and does not contain the CN. As expteced, it's all good if the extension
 is missing since the CN correctly contains the host name. Also, it's working
 propperly once I add the CN into the subjectAltName field but that's kind of
 weird - isn't it ?

 Regards,
   Thomas
 __
 OpenSSL Project http://www.openssl.org
 User Support Mailing Listopenssl-users@openssl.org
 Automated List Manager   majord...@openssl.org
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: strong TLS connections

[Michael Sierchio]

On Fri, Oct 7, 2011 at 7:40 PM, Kristen J. Webb kw...@teradactyl.com wrote:

 My understanding is that a TLS connection with a server cert
 only identifies the server to the client.  This leads to a MiTM
 attack, where the mitm can impersonate the client because the server
 has not verified the client.

Your understanding is flawed - while in the scenario you mention there
is no binding of a client identity to a public key, SSLv3/TLS are not
vulnerable to MITM - no third party can manipulate the stream without
being detected.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: Differences between RSA and ECDSA - Conceptual and Practical

[Michael Sierchio]

On Sat, Oct 8, 2011 at 6:39 AM, Rick Lopes de Souza
dragonde...@gmail.com wrote:

 Another thing that i know is that RSA can only sign things that are smaller
 than the size of the key used.

No - you can sign a message of arbitrary length - a suitable message
digest is what is encrypted (well, decrypted) in the RSA digital
signature scheme.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: Reliable identification by DN (or something else) for commercially-signed certs?

[Michael Sierchio]

Does any commercial CA still issue client certs?  Most of them got out
of this business because the liability for them outstrips the revenue
benefit.

While it makes sense to have server certs issued by a commercial CA,
why would you even want client certs signed by a commercial CA?  When
you are both the RA and the CA, you may control any opaque identifier
you wish to bake into the cert. And you may have your own protocol for
verification of identity, whereas the only thing the cert attests to
in the case of a commercial CA is possession of the private key and
binding to (usually) an email address, since that's how the workflow
assures the identity.

- M

On Sun, Jun 26, 2011 at 11:39 AM, Leo Richard Comerford
leocomerf...@gmail.com wrote:
 Hello.

 I'm looking at setting up a service using OpenSSL with client certs
 signed by one of the (fairly-)big-name browser cabal commercial CAs.
 But (as normal) I only want to allow certain, authorised clients to
 connect, not anyone with a valid certificate from the commercial CA.
 So after verifying the client cert against the trusted CA cert(s) I
 have to check that the client is in the subset of authorised clients.
 Instead of having a second form of identification like a
 username/password, I would like to use the client cert for this
 authorisation step too. So I would like to make use of a whitelist of
 the certs of authorised clients.

 What should I use to whitelist certificates by? Specifically, what can
 I whitelist on to prevent false positives? For example, the obvious
 thing seems to be Distinguished Name. But can I safely assume that any
 two certificates issued by a big-name commercial CA to two different
 entities will have different (full) DNs? More precisely, is it safe to
 assume the same thing about any two certs, issued to different
 entities, which *pass verification by the CA cert(s) of* that big-name
 CA? - viz. the cross-signing spaghetti of doubt and so on. If the
 answer is 'no' - if DN (or DN alone) won't guarantee uniqueness under
 those circumstances - is there some other field, or combination of
 fields, which would? DN plus Issuer? SubjectAltName?

 Obviously by using a commercial CA in this way I'm placing a certain
 amount of trust in that commercial CA. I'm willing to take the gamble
 that the CA won't deliberately betray me, and that it won't screw up
 in some new and unexpected fashion. But if there's some way in which
 big-name CAs are known to routinely screw up which makes
 identification by DN (or whatever) unreliable then of course I'll have
 to protect myself against that.

 Finally, I'd much rather avoid rolling my own if possible. If there's
 some well-established utility or script (or even a cheat-sheet) for
 doing what I'd like to do then I'll happily adopt that; I just haven't
 been able to find any yet. Similarly, if what I'm trying to do is
 impossible or too bloody hard then I'll happily take 'no' for an
 answer. But at the moment I'm just at a bit of a dead end, unsure what
 my options are (or aren't) - any advice would be much appreciated.

 Leo Richard Comerford.
 __
 OpenSSL Project                                 http://www.openssl.org
 User Support Mailing List                    openssl-users@openssl.org
 Automated List Manager                           majord...@openssl.org

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: Compressed ECC points - X9.62 vs IEEE1363

[Michael Sierchio]

http://csrc.nist.gov/groups/ST/toolkit/documents/Examples/DRBG_ANSI_X9-62-1998.pdf

On Tue, May 3, 2011 at 3:28 AM, Julien Poumailloux julien.p...@free.fr wrote:
 Dear subscribers of the openssl-users list,

 I read in the code of openssl (crypto/ec.h) that the compression of ECC
 points is compliant with the X9.62 standard. Unfortunately I don't have
 access to this standard. I am required to use compressed ECC points
 compliant with the IEEE1363-2000 standard. My question is the following: is
 the compression algorithm for ECC points in X9.62 the same as in IEEE1363?

 If anyone has an answer, I would appreciate any help!

 Thanks,
 Julien Poumailloux
 __
 OpenSSL Project                                 http://www.openssl.org
 User Support Mailing List                    openssl-users@openssl.org
 Automated List Manager                           majord...@openssl.org

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: DH session Key length

[Michael Sierchio]

The private exponent length need only be sufficient to make a brute
force search (using the public exponent as a target) computationally
infeasible, since the discrete log problem is still in the hard
category.

Cogent DH Private Exponent recommendations are always stated in terms
of P, e.g., x : 1  x  (p-1)/2.

- M

On Mon, Apr 18, 2011 at 7:25 PM, Mike Mohr akih...@gmail.com wrote:
 You might take a look at RFC 3526:

 http://tools.ietf.org/html/rfc3526

 It is my understanding that the DH exponent can be significantly
 shorter than the modulus without compromising security.  RFC 3526 is
 from 2003, but I haven't found anything published since then that
 would make me think its assertions are invalid or outdated.  The
 paranoid tinfoil hat crowd can probably take twice the maximum bit
 count from section 8 (620x2=1240) and be happy.

 Mike

 On Mon, Apr 18, 2011 at 8:01 AM, ikuzar razuk...@gmail.com wrote:
 Hello,
 I 'd like to know the length of DH session key generated by
 DH_compute_key(unsigned char *key, BIGNUM *pub_key, DH *dh) . Here :
 http://www.openssl.org/docs/crypto/DH_generate_key.html
 It is said that key must point to DH_size(dh) bytes of memory. is 128 bits
 the default length ? how can I adjust this length according the symetric-key
 algorithm I use ( AES128/ICM)
 Thanks for your help.


 __
 OpenSSL Project                                 http://www.openssl.org
 User Support Mailing List                    openssl-users@openssl.org
 Automated List Manager                           majord...@openssl.org

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: DH session Key length

[Michael Sierchio]

Addendum - depending on the use of DH (usually using the DH shared
secret as a basis for key exchange), the choice of prime is more
important than private exponent length.  Safe primes or strong primes
are warranted.  Most systems use small generators (e.g., 2).

- M

On Mon, Apr 18, 2011 at 7:25 PM, Mike Mohr akih...@gmail.com wrote:
 You might take a look at RFC 3526:

 http://tools.ietf.org/html/rfc3526

 It is my understanding that the DH exponent can be significantly
 shorter than the modulus without compromising security.  RFC 3526 is
 from 2003, but I haven't found anything published since then that
 would make me think its assertions are invalid or outdated.  The
 paranoid tinfoil hat crowd can probably take twice the maximum bit
 count from section 8 (620x2=1240) and be happy.

 Mike

 On Mon, Apr 18, 2011 at 8:01 AM, ikuzar razuk...@gmail.com wrote:
 Hello,
 I 'd like to know the length of DH session key generated by
 DH_compute_key(unsigned char *key, BIGNUM *pub_key, DH *dh) . Here :
 http://www.openssl.org/docs/crypto/DH_generate_key.html
 It is said that key must point to DH_size(dh) bytes of memory. is 128 bits
 the default length ? how can I adjust this length according the symetric-key
 algorithm I use ( AES128/ICM)
 Thanks for your help.


 __
 OpenSSL Project                                 http://www.openssl.org
 User Support Mailing List                    openssl-users@openssl.org
 Automated List Manager                           majord...@openssl.org

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: encrypting long strings

[Michael Sierchio]

Despite what others have said, RSA is perfectly reasonable (if slow) to use
for encryption.  If you do, you should use OAEP/OAEP+ rather than the
common/naive method of padding.

http://cseweb.ucsd.edu/~mihir/papers/oaep.html

The Wikipedia article is a good starting place

http://en.wikipedia.org/wiki/Optimal_asymmetric_encryption_padding

and there's a brief article here

http://www.rsa.com/rsalabs/node.asp?id=2346

more detail here

ftp://ftp.rsasecurity.com/pub/rsalabs/rsa_algorithm/rsa-oaep_spec.pdf

- M

On Sat, Jul 10, 2010 at 11:13 AM, Jeffrey Walton noloa...@gmail.com wrote:

  The general approach is to encrypt data using a symmetric cipher (e.g.,
  AES-256) with a randomly-generated key, and then encrypt that symmetric
 key
  with the RSA (public) key.
 AES-256 requires a RSA modulus with an equivalent strength, which is a
 15360 (IIRC). If you choose RSA-1024 or RSA-2048, you are off by
 orders of magnitude.

 On Thu, Jul 8, 2010 at 11:43 PM, Phillip Hellewell ssh...@gmail.com
 wrote:
  The general approach is to encrypt data using a symmetric cipher (e.g.,
  AES-256) with a randomly-generated key, and then encrypt that symmetric
 key
  with the RSA (public) key.
 
  And for the symmetric encryption you'll also have to make a decision
 about
  what mode to use (ECB, CBC, CTR, etc).  Whatever you do, don't use ECB :)
 
  Phillip
 
  On Thu, Jul 8, 2010 at 7:40 PM, Chuck Pareto chuckda...@gmail.com
 wrote:
 
  Is there an algorithm that I can use, similar to RSA with public/private
  key, that will allow me to encrypt really long strings (like an
 email/text
  file)? Actually no limit on the size would be ideal.
 
 
 __
 OpenSSL Project http://www.openssl.org
 User Support Mailing Listopenssl-users@openssl.org
 Automated List Manager   majord...@openssl.org

Re: Random Numbers

[Michael Sierchio]

On Tue, Mar 30, 2010 at 11:48 PM, P Kamath pgkam...@hotmail.com wrote:

 I said it is an RNG, not cryptographic RNG.  By adding current time source,
 however crude, and doing a sha1/md5, why should it not be cryptoPRNG?  What
 properties should I look for?


 Taking a hash of an entirely predictable (or narrowly bounded) value adds
no entropy.

Re: Post-2010 future of the OpenSSL FIPS Object Module?

[Michael Sierchio]

Steve Marquess wrote:
 In the three years since the open source based FIPS 140-2 validated
 OpenSSL FIPS Object Module became available many software vendors have
 directly or indirectly utilized it to realize substantial cost and
 schedule savings.  We're glad to see the widespread benefits of these
 hard won validations

Steve -

Forgive my ignorance, but are you a 501(c)3?  Can you communicate that
in a signature line so it's obvious?

Do you have a list of commercial vendors who use OpenSSL?  A list of
companies that use it internally (that would be nearly everyone who
uses Linux, UNIX, *BSD, etc.)?   That would be the basis of fundraising
activity (I mean making phone calls, which is something nearly everyone
can do).  $150,000 is not an intimidating amount for anyone who's done
fundraising.

- M

-- 
Michael Sierchio
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: A PKI in a web page

[Michael Sierchio]

Richard Salz wrote:

 I'm making available my small set of web pages and Perl script that 
 implement a self-service PKI built around OpenSSL. 

Awesome, Rich!  Thanks.

- M
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: Diffie-Hellman key exchange : Preventing MITM attack

[Michael Sierchio]

Ram G wrote:

 I would like to run a design by you. The requirement (and the constraint) is
 that I have to design a secure communication channel without using
 certificates. I'm trying out DH key exchange.

An unfortunate, if common, misnomer.  DH key agreement is a better
term, since it denotes that an implicit master, pairwise secret
exists between any two participants - the result of modular exponentiation
using one's own private key and the counterpart's public key.

 My proposed design is a two step process for communication:
 
 1) Use Anonymous DH and estiablish the shared secret. This is done at some
 predefined interval - may be once everyday or once every week.

See the SKIP design, which never uses the master secret directly,
but has a course-grained counter (time_t) to prevent replay
attacks.

 2) In the second step of the communication, we will use the shared secret
 from step 1 for authentication. This will be done using Diffie-Hellman key
 exchange with pre-shared keys (DHE-PSK, support for which is added in
 version 1.0.0 )
 
 3) Once the client is authenticated, all communication is encrypyted using
 the master secret derived from DHE-PSK.

See the above comments - don't use the master secret directly.

 This removes the need for me to establish passwords before two parties can
 communicate and generates passwords on the fly.
 
 Will this secure me against man-in-the-middle attacks which is possible with
 anonymous DH and without authentication ?

Yes, properly implemented, and assuming integrity of private keys.  An
intermediary cannot play without the shared secret.  You require only
trusted (possibly OOB in your scenario) publication of public keys.

-- 
Michael Sierchio  +1 415 378 1182
PO Box 9036ku...@tenebras.com
Berkeley CA 94709  http://xijiaoshan.blogspot.com

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: Diffie-Hellman key exchange : Preventing MITM attack

[Michael Sierchio]

Victor Duchovni wrote:

 No. Without a previously arranged shared secret and no trusted introducer,

DH doesn't require anything but mutual knowledge of public
keys, since the shared secret is implicit.  Either OOB or
via a trusted directory service, or a cert binding the identity
of a principal to a pubkey suffice.

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: Diffie-Hellman key exchange : Preventing MITM attack

[Michael Sierchio]

Victor Duchovni wrote:

 Bootstrapping authentication requires an out-of-band secure channel for
 key exchange (or initial delivery of keys of trusted introducers).
 

Agreed.

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: Signing a file using HMAC

[Michael Sierchio]

toby.wa...@fxhome.com wrote:
 Hello,
 
 I am using the dgst command to sign a file, I'm also using the -hmac
 option. I then want to verify the signature by decrypting it and
 checking the hash. The problem is the hash never seems to match.

It's unclear to me what you are trying to accomplish conceptually.
HMAC has nothing to do with signing, but is a keyed hash used as
an authenticator for (possibly) pairwise message authentication.  It
cannot function as a signature, because it cannot be verified by
a third party.   Pick one.

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: certificate expiration in hours

[Michael Sierchio]

Lucas Mocellin wrote:

 I would like to generate a certificate valid in hours, does someone know
 how to do it? is that possible or I have to manage this hours by myself?

Why?  What kind of cert? What is the intended use for the cert?  If it's for
the purposes of restricting access to a given time window, use a different
mechanism.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: certificate expiration in hours

[Michael Sierchio]

Lucas Mocellin wrote:

 I'm sorry, I don't understand very much about, but let's try.

Bad idea.  Certs bind identity to public keys.  Authentication
is not authorization, and it is extremely important that you
understand the semantics before proceeding, IMHO.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: I want you to do my homework for me.

[Michael Sierchio]

Michael S. Zick wrote:
 On Sat May 2 2009, Miguel Ghobangieno wrote:
 Furthermore I am aware that you opensource coders are all a buch of 
 mysoginist sexists; 
 for the most part you are all _men_. The EEOC is going to hear of THAT 
 aswell. 
 
 http://www.urbandictionary.com/define.php?term=mysoginist

I think you are perhaps missing the Dadaist flavor of the post.

- M

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: hmac digest wrong?

[Michael Sierchio]

Ronald Hatcher wrote:
 Hi there -
 
 I'm trying to create an hmac digest which works OK from php as:
 
 $signature = hash_hmac('sha1', ronald , $apikey);
 
 However, I get a different digest using:
 
 echo ronald | openssl dgst -sha1  -hmac $apikey
 
 Is there something obvious I'm doing wrong here?

Luckily, yes.  The latter version has an extra char.

man echo.

try `echo -n ronald | openssl dgst -sha1  -hmac $apikey`

which doesn't add the '\n' that your version does.


-- 
Michael Sierchio  +1 415 378 1182
PO Box 9036ku...@tenebras.com
Berkeley CA 94709  http://xijiaoshan.blogspot.com
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: documentation/description of RSA PEM file format used by OpenSSL

[Michael Sierchio]

Tomasz Kaźmierczak wrote:
 I've managed to base64 decode a public key (at least I think so;).
 Now I'm trying to understand how to interpret the key data. I've found the
 definitions of RSAPublicKey and RSAPrivateKey structures (in the
 PKCS #1: RSA Cryptography Standard), but there is no information
 about what are the lengths of those structures' fields.

You should locate and follow one of the ASN.1 tutorials floating
about on the web before proceeding any further.  The syntax of
the representation contains tags that identify to contents of
components of an object, and their length in octets.  And more,
sometimes. ;-)


-- 
Michael Sierchio  +1 510 962 5595
PO Box 9036ku...@tenebras.com
Berkeley CA 94709  http://xijiaoshan.blogspot.com
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: Where to store client PEM certificates for an application

[Michael Sierchio]

Edward Diener wrote:

 Well I asked whether protection for the client side certs were needed,
 and how this might be done, and I was told I was barking up the wrong
 tree, so to speak. I felt this way from the very beginning but my
 employer wanted to get other opinions.

You are either unclear on the concepts that others are trying to
convey, or are abusing the terminology.  Certs don't require
protection, they don't contain any private data, etc.

 Once again the specific issue is that the MySQL server database has a
 certificate from a CA authority with a server public-private key and my
 client application was issued the same certificate from the CA authority
 with a a client public-private key. 

No, it wasn't issued the same certificate.  Such an assertion is absurd.

  I need to pass the file location of
 the client CA certificate/public-key/private-key ...

client CA certificate/public-key/private-key is an indication you
should stop talking and start listening.  It's clear that there are
fundamental concepts here that you have yet to grasp, and yet in
response to attempts by others to instruct you, you just keep
telling us how smart you are, while demonstrating the opposite.
Anyone who talks of hiding the client certs is clueless.

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: How to use a hardware RNG with openssl?

[Michael Sierchio]

Gerd Schering wrote:

 So , if I get it right: we have a true random source to seed the PRNG
 and this produces true random numbers?

No.  There is no such guarantee using any PRNG.  PRNGs provide a much higher
bitrate than hardware RNGs or system sources of entropy.  They use cryptographic
hash functions to whiten data, i.e., these hash functions have the property 
that
a change in a single bit of input changes, on average, half the output bits.

Presumably you want a source of nicely-distributed random bits which are
computationally infeasible for another party to predict.  If you want a
security guarantee (reduction proof that if PRNG is insecure, it implies
SHA1 is insecure, etc.), then there are design and operational constraints
to consider (e.g. generating only 2^N bits with 2^M bits of input from a RBG).
Oh, and you'll have to supply the proof -- it's missing on all the commonly
used PRNGs.

- Michael

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: Do you have to pre-pend 16 bytes to a raw value before RSA encryption

[Michael Sierchio]

Peter Walker wrote:

 The purpose of my application is to send a credit card number in
 encrypted format.

Then use OAEP.

- M
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: Do you have to pre-pend 16 bytes to a raw value before RSA encryption

[Michael Sierchio]

Kenneth Goldman wrote:

 What padding are you specifying?  I suspect that you are specifying
 no padding, in which case the size of the input must be the same
 as the size of the key.

No.  The input is the same size as the *modulus*.

When used in encryption the recommended approach for RSA is to pad
every block, and not to encrypt MODULUS-SIZE bytes of plaintext.  There
are very good reasons for this which will not be obvious to all readers
of this thread, but you would want to use OAEP (Optimal Asymmetric Encryption
Padding) if you are doing something other than signing (e.g. using RSA for
to encrypt a session key).

If the OP means what he says, which is *signing* a public key (the purpose
of which is entirely unclear to me), then the plaintext will be the hash of
the pubkey, right?  In which case the padding will have to be sufficient
to fill the remaining RSA block size, whatever that is.

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: X.509] Certificate Generation without PoP

[Michael Sierchio]

Silviu VLASCEANU wrote:

Hello,

I am developing an application which also has some CA functions. The 
application knows the public key, KpC, of a client which has a priori 
proven to this app the possession of KpC through an out-of-band mean. 
Therefore, when the application calls the CA functionality to generate 
the client's certificate, it should not need to provide the 
Proof-of-Possession of KpC by the client.


My question is which are the steps to be taken by the application, in 
order to have a certificate generated for KpC, without providing any PoP 
to the CA?


Any comments are welcome. Thank you in advance for your answer!


I have the same queasy feeling upon reading this as I would
a request for instructions on how to remove one's own appendix.

The only advice I can offer is: don't.

- M
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

why we call it entropy

[Michael Sierchio]

Von Neumann counseled Shannon to call it entropy because no one
really knows what entropy is. ;-)

I wanted to say that it's inherently problematic to use things like the
randomness in the interarrival time of events like interrupts, etc.
to gather entropy -- Ted has touched on this with his comment on
solid state disk drives, etc.

A bit stream may have 1 bit of entropy per bit of message (i.e. an
entropy of 1), and therefore be incompressible -- perhaps what Schwartz
thinks he means when he says truly random -- and be entirely predictable.

We want nicely-distributed random numbers without apparent bias,
with an apparent entropy of one, so that 10 bits of key material
is really 10 bits of key;  what makes such numbers cryptographically
useful is that no amount of collected material enables us to
predict bits anywhere else in the stream (past or future, if viewed
temporally).

I have given Herr Schwartz enough of my grossmutterlich Freundlichkeit
for one day.  Ppppt.

- M





__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: why we call it entropy

[Michael Sierchio]

Michael Sierchio wrote:


A bit stream may have 1 bit of entropy per bit of message (i.e. an
entropy of 1), and therefore be incompressible -- perhaps what Schwartz
thinks he means when he says truly random -- and be entirely predictable.


In case this isn't obvious, apply Von Neumann's corrector to the fractional
component of the binary representation of a transcendental number.

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: Wondering if a vendor product might be vulnerable to existing (fixed) bugs, despite showing current version number

[Michael Sierchio]

Samuel Lavitt wrote:

I am wondering how I could determine, with only access to the compiled 
binary, if this version has any missing security fixes 


The worst vulnerabilities (and your time might be valuable, so prioritization
might be important) have published exploits available.

Black hat black box testing, IOW.

My profession prevents me from directly pointing you to such tools, but
a modest amount of effort can lead you to them.

Don't put too much faith in version strings.

- M
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: Problems with revoked certificate

[Michael Sierchio]

albertlb wrote:


I am using a debian pc with openssl and openvpn. The problem is I have
revoked a user certificate but the user still has access to the vpn. In the
crl.pem file appears the reference to this user. What could It happen?

Thank you http://www.nabble.com/file/p18487517/openssl.cnf openssl.cnf 


Someone has already answered the CRL question, but I feel the need
to point out that certificate validity isn't adequate for access
authorization.  That is, conflating authentication and authorization
is usually a mistake.

- M
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: Please help: very urgent: Query on patented algorithms

[Michael Sierchio]

RC4 is owned (and trademarked) by RSA Security Inc, but they are no
longer enforcing the patent,


RC4 was never protected by patent, but by trade secret.  When the
details of the algorithm were published, Ron Rivest himself suggested
calling the alleged RC4 ARCFOUR.  It is indeed a trademark of RSA
Security.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: RAND_load_file takes a long time to load 1K bytes from /dev/random

[Michael Sierchio]

Glenn wrote:


Lack of entropy?  Try using /dev/urandom


/dev/urandom supplies (statistically useful) random bits -- no
claims are made about entropy.

- M
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: 2038 date limit

[Michael Sierchio]

Brant Thomsen wrote:

The C++ compiler in Microsoft's Visual Studio 2005 (and later) makes time_t
a 64-bit number when compiling 32-bit code.  Older compilers, such as Visual
C++ 6.0, make time_t a 32-bit number, which would cause year 2038 issues.


I'd very much like to see TAI64 adopted where one second granularity
is required (sufficient for all dates in the past and future until
the EOL of the universe), and TAI64n (requiring 64 + 30 bits in some
representation) for nanosecond accuracy.

Dan Bernstein's libtai is a good starting point.  Many things
will have to change, including the ntp protocol, but a
more rational representation for time values will have plenty of
good side-effects.

- M
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: Wider fallout from Debian issue?

[Michael Sierchio]

David Schwartz wrote:

 ... Suppose I include a randomish

string in my message 46e8bd8ceae57f8b7af66536e7859bad. Any attacker might
see this message -- it's public. So he can certainly try that string as your
password. So will you now run off and add it to a blacklist, since it's
clearly now a weak password?


I suppose the distinction between known and weak is too fine
a semantic point for you?
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: Wider fallout from Debian issue?

[Michael Sierchio]

David Schwartz wrote:

Every known key, provided there are not too many known keys, is weak. 


Once again, you have a very idiosyncratic lexicon of cryptographic
terms.  How about if we use these words the way cryptographers do?

A weak key is one that causes a cipher to leak private data in the
ciphertext, or reveal key structure in a timing attack, or makes
the implementation vulnerable to an adaptive chosen-plaintext attack,
etc.  A diminished keyspace reduces the number of keys to be attempted
in a brute force attack.  This may or may not be significant.  If the
reduction in keyspace means a brute force attack effort is reduced by
half to merely half the life of the universe, that might be a worthwhile
tradeoff.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: DH Prime Question

[Michael Sierchio]

Julian wrote:
My fear is that get a hold of P will allow for someone else to use it to 
start a protocol disassembly. For instance anyone could create a 
DHE-RSA-AES256-SHA TLS server and use P to listen for connections, of 
course if would have to have a cert signed by CA to proceed even if they 
have P.


The protocol here is TLS where each client is a server, so shouldn't 
each client/server have their own DH P?


No.  All participants share a prime generator and a modulus. A DH
secret key is therefore essentially merely a random string of bits
of a certain length.  The corresponding public key is p^privkey mod m.

Trust requires you have some mechanism to know that a given set of
bits is the pubkey belonging to the other party.

The benefit of DH is that once you and your correspondent have each
other's public keys, you can begin encrypted communication without
a handshake.  There is an implicit pairwise shared secret which you
can use to generate session keys via some established mechanism (see
SKIP as an example).

- M



__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: Accessing encrypted messages after cert expires

[Michael Sierchio]

Steffen DETTMER wrote:


For operational, administrative and forensic concerns I think it
is important to know the key generation time as well as who
generated it in exactly which way, who gave the key to whom when
and why and so on - maybe even including a transactional log of
every key usage ever done.


I'm not suggesting that this isn't useful, just that it is not
a defect that it isn't part of the key format itself.

For compliance purposes, how do you prove generation time?  I claim
that the relevant time is that of the first CSR.  Operationally,
a timestamp and a nonce as part of a challenge created by the CA,
included in the CSR which is signed by the subject privkey, makes
sense.  And hygiene dictates that the only use of the private
key permissible before issuance of the certificate is in signing
the CSR.

If the timestamp isn't generated by a trusted third party, I don't
think it's of much value.

- M

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: Accessing encrypted messages after cert expires

[Michael Sierchio]

Kyle Hamilton wrote:
On Sun, Mar 16, 2008 at 



Since it's infeasable to store all of the possible keypairs in the
number of atoms in the universe, your assertion holds no water.  


Did you do the calculation? The number of primes less than or equal
to 512 bits in length number around 10**150,  but not all are usable.
Many are disqualified by research into weak decryption exponents which
different parties believe starts with d in (N**0.292, N**0.500).

Standard choices for e (by convention picked for easy exponentiation when
verifying signatures) further  limits the field.

Picking p, q that are within a fairly narrow range in order to guarantee
a predictable modulus len (2048, not 2047 or 2049) further restricts the
candidates.

Yeah, you won't run out of primes, but you won't run out of space
for the ones you have used.
- M
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: Please take me off

[Michael Sierchio]

navneet Upadhyay wrote:

me too


Cancel Your Own Goddam Subscription

- Wm. F Buckley
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: Accessing encrypted messages after cert expires

[Michael Sierchio]

David Schwartz wrote:


What I think Michael Sierchio was saying, though, was something different.
He's not saying to treat a certificate as revoked, he's saying not to issue
a certificate. Basically, he's saying a CA could refuse to issue a
certificate for any key that it had ever seen before in any other context. I
think this would be a mistake for a lot of reasons, not the least being the
hit-or-miss aspect of having previously seen the key.


I'm saying that matters of policy are within the purview of the
Registration Authority and/or Certificate Authority.  The relying
party agreement associated with the CA, and perhaps baked into
the certificate via reference, can spell this out.

If it's your policy not to reuse keys, or allow their use beyond
the lifespan of the certificate, then the enforcement mechanism
for this MUST be in the CA.

I don't understand your hit-or-miss aspect - a CA must keep track
of all the issued certificates back to the beginning of time.  It is
trivial to know whether a key has been used before.

And my objection remains to your notion that the private key format
should be extended to include generation date.  Even if you are
to reissue/resign a cert with the same subject pubkey, you still
have a record of when the key was first placed into use.

I also don't understand why you think it would be appropriate to
use the same key in different certs.  It is much more common to
have different certs with different keys for different purposes.
For example, if you wish to claim non-repudiation, then the CA
may require that the private key is embedded in a token device
where the keypair was generated, and is not otherwise accessible.
Such a key would be used for signing only, presumably, for a
number of very good reasons.  The same entity may have an SSL
client cert, an encryption cert, etc.

The OP was asking about the mechanics of signature verification
beyond the expiration date of the signing cert.  I think we've
answered that.

- M
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: Accessing encrypted messages after cert expires

[Michael Sierchio]

David Schwartz wrote:

Michael Sierchio:


If it's your policy not to reuse keys, or allow their use beyond
the lifespan of the certificate, then the enforcement mechanism
for this MUST be in the CA.


I completely disagree. If this were true, CA's would generate the private key 
as part of the certificate issuing process.


That doesn't follow.  In any case, the only place where certificate issuing
policy can be enforced is the RA and/or CA.  The rest of your argument is
just as specious, and I could make a career out of correcting your errors,
but you're determined not to learn.

- M
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: Accessing encrypted messages after cert expires

[Michael Sierchio]

Kyle Hamilton wrote:


Certificate issuance is a statement of identity binding for a given
key at a given assurance.  No more, no less.


No, it isn't.  It's often more.


A CA does not and cannot specify the value of the data which can be
encrypted or protected by any given key.  


Irrelevant to the discussion.


... It specifies things that
third parties can know and rely on.  Only the principal itself can
know what it's actually going to use the key for.


No, key usage restrictions are certainly within the realm of what
a CA will bake into a cert.  And relying parties may choose not
to accept a cert for a given purpose if that purpose is not
included in key usage extensions, for example.

For example, you certainly can use a key to produce a digital
signature, even if the certificate that binds the public key
to that entity says otherwise.  But no one should accept the
signature as valid.  In fact, the signing may be grounds for
revoking the certificate.


Remember, the CA (and X.509 certificate chains) are only a relatively
efficient means of transferring trust via policy.  It is NOT the only
way to transfer trust.  


Irrelevant to the discussion -- I was arguing against adding time of
generation data to the private key format.  I don't know of any serious
cryptographer or security expert who advocates this, and I certainly
don't.


Please remember that there are uses for keys outside the PKI.  This is
why private key storage formats should have a timestamp-of-generation


Irrelevant, and fallacious.  PKI is not a use for keys, it provides
mechanisms of finding appropriate identity/key associations and
validating these.

There are good arguments for NOT adding ad hoc changes to a standard --
especially when they are based on a paucity of understanding.

- M
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: Accessing encrypted messages after cert expires

[Michael Sierchio]

Kyle Hamilton wrote:

On Sun, Mar 16, 2008 at 10:44 PM, David Schwartz [EMAIL PROTECTED] wrote:

 If you can't trust the system that generates and stores your private key, 
you're screwed anyway. So I don't see that this argument has any validity.


The issue is 'who is trusting what?'

David's apparent statement is the person trusting the time is the
person generating the key.
Michael's apparent idea is if you're generating it and including it
in the key format, then you're making an assertion which must
trustable by people other than the person generating the key.


My point is that number theory and TAI64n aren't related.  Certificate
policy and matters of key reuse probably need to take both into account.

Look, all RSA keypairs are of a given pubkey len are finite in number,
and already exist mathematically.  I hereby give them a timestamp of zero.
Oh, did you mean when YOU started using them?  What's the point of that?
To prevent reuse?  Who cares about that?  Perhaps your CA has a policy
about key lifespan for encryption, or for signing purposes?  Perhaps
your CA requires that private keys used for signing never leave the
device they are generated on?  All quite reasonable, and none of which
argue for a change in either of the common forms of representing
private keys.

- M
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: Accessing encrypted messages after cert expires

[Michael Sierchio]

David Schwartz wrote:


You have to have absolute trust in any entity that will generate or store your 
private key. Thus you can trust any information in it -- anyone who could put 
in bogus information could give away your key to strangers. (By absolute trust, 
I mean with respect to anything you would use that private key for.)


Pick a keypair, any keypair.  It has existed in a mathematical sense
since mathematics has existed, or longer, if your a mathematical
idealist.  What do you have in mind?  I give them all a creation date of 0.

NotValidBefore and NotValidAfter are perfectly fine concepts that do not
violate the laws of modularity, and are where they belong.  These come
from the signing authorities policy, which also may preclude key reuse
after expiry (you can't sign with the private key after expiration, but
verification of any messages signed in the validity window succeeds).
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: Accessing encrypted messages after cert expires

[Michael Sierchio]

Kyle Hamilton wrote:


A key's lifetime is, cryptographically speaking, the amount of time
for which it can be expected to provide a sane level of security in
relation to the value of the data which it protects.


Right, which is a matter of consensus best practice, we hope...


Of course, cryptography is just a means of applying a policy to a
piece of data.  If you share a means of decryption, you also share a
piece of trust with whomever you share that means with that they won't
violate that policy, even though the policy is advisory (i.e.,
non-enforceable) once the data is decrypted.


I think you need to be more careful about what is trusted.
In the case of a signed message, our trust depends on a
number of things -- that the message was signed during the
validity period of the signer's cert, that the cert declares
the key to be valid for that use, and perhaps trust in the CAs
policy enforcement and revocation methods, CRL publication, etc.
We trust that, absent a key revocation for any reason, including
expiry, that a private key remains under the exclusive control of
the signer.  Signatures might require third party digest timestamps
for non-repudiation of the validity of the signature wrt time of
signing prior to a trusted date.

Anyway, in the case of RSA keypairs we don't manufacture them, we
discover them.  They're already there, we just search for our p's and q's
in the appropriate range and rely on chance starting conditions to find
some not in use.  I suggested, but not entirely in jest, giving them all
a timestamp of 0.  Creation date is a useless concept.  Not valid before
and Not valid after attributes make enormous sense, and are where they
ought to be.

The trust conferred on a signature derives from signature validation,
which requires certificate validation.  One part of the validation is
that the message in question was signed during the validity period
as defined by certificate policy.

You may argue, and get me to agree, that cert reissue/resigning with
the same SubjectPubkeyData is a bad idea.  Make 'em generate keypairs.
Keep a list forever of pubkeys seen in certs and reject any that appear
in CSRs.  Your storage requirements won't rival that of Youporn, or
Wikipedia.

b


__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: Accessing encrypted messages after cert expires

[Michael Sierchio]

David Schwartz wrote:

 ... An attacker can start trying to break your key as soon he has your public 
key.

Issuance date of the cert suffices.  It's still not an attribute of
the private key.

In any case, you may of course need to validate an old signature, and the
mechanics for that have been elaborated here.  You don't need to perform
the validation during the period defined by the cert, you have that absolutely
wrong.  A signature with a timestamp outside the valid dates of the cert is
invalid, but you may have a need to validate signatures long after a cert
expires.

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: Accessing encrypted messages after cert expires

[Michael Sierchio]

Patrick Patterson wrote:

Actually, what you care about are the keys associated with the certificate. 
For encryption, you've got content that is encrypted with the public key, and 
decryptable only with the private key. Since the certificate is your public 
key signed by some Certificate Authority or other (or, itself), then after 
the certificate expires, most software will not let you or others encrypt 
things with that public key. However, since you are still in possession of 
the private key, you should still be able to decrypt everything just fine.


A cert is more than a public key signed by a CA -- it's a binding of
that key to an identity (in this case an email addr?).

Never mind the red herring of calling it an SSL cert, it's apparently
used here for the purposes of SMIME encryption, which requires the
use of two public-private key pairs in the case in which an email is
encrypted and signed (and sent to another party).

For enveloped data, the content-encryption key is encrypted for each
recipient (using the recipient's public key);  for signed messages, the
private key of the sender is used appropriately to generate the
signature.  This requires that both the sender's public key and the
recipient's private key be known and usable into the foreseeable
future, independent of cert expiration.

Keys don't expire -- certificates do.

Expiration of a cert should only render invalid any messages signed
(in the case of expiration of the sender's cert) or encrypted (in
the case of expiration of the recipient's cert) after the expiration
date.  AFAIK many (most) MUAs which support SMIME will keep certs in
their database forever, until purged.

And why would you need to protect a private key when its associated
public key is longer used for encryption, and when the key itself
is no longer used for signing?

- Michael
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: Accessing encrypted messages after cert expires

[Michael Sierchio]

David Schwartz wrote:

Arguably, you shouldn't do it even once, because it's extremely easy
to fall into the pattern of one key and one key only in the systems
design or implementation.  I can't remember who coined the phrase, but
it's not good crypto hygeine.


I have argued many times that not including the creation date in every private 
key data format was a *huge* mistake.


And you have argued wrongly.

Such matters of key usage policy are in the domain of the CA and/or RA --
They have nothing to do with cryptography per se.

- Michael
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: MAC

[Michael Sierchio]

Main, James J Civ USAF AMC DET 3 AMCAOS/DOHJ wrote:
Is there a driver available for MAC  using ActivClient CAC 6.1?  If so 
where is it available.


Hey, Jim -

does ActivClient present itself as a cryptosystem service, a la
PKCS#11 or Microsoft's Smart Card interface?

Regards.

- Michael
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: Accessing encrypted messages after cert expires

[Michael Sierchio]

David Schwartz wrote:

Arguably, you shouldn't do it even once, because it's extremely easy
to fall into the pattern of one key and one key only in the systems
design or implementation.  I can't remember who coined the phrase, but
it's not good crypto hygeine.


I have argued many times that not including the creation date in every private 
key data format was a *huge* mistake.


Furthermore --

How do you know what time it is?  How do I know you know what time
it is?  Do I trust you to put the correct time, or even a monotically
increasing sequence, into such a structure?  See?  It's utterly
useless, even as a thought experiment.  As soon as you need reliance
on the truth value of an assertion (validity of a timestamp), you're
already in TRUST territory.

Might as well let the CA decide not to reissue/resign a cert with an
existing pubkey.

- Michael
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: Accessing encrypted messages after cert expires

[Michael Sierchio]

David Schwartz wrote:


If you can't trust the system that generates and stores your private key, 
you're screwed anyway. So I don't see that this argument has any validity.


A timestamp is not an attribute of a private key.  It's utterly
irrelevant.  If your purpose is to require that new certificates
bound to an entity upon expiration of old certs have a different
key, do that.  Multiplying your misunderstanding by zero does
not improve matters, even for large values of zero.

- M


__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: Compiling on a Mac

[Michael Sierchio]

Joel Christner wrote:


The issue I'm seeing is when compiling:

mac# openssl version
OpenSSL 0.9.7l 28 Sep 2006
mac# gcc blowfish.c -o blowfish
...
Undefined symbols:


Basic C compiler/linker usage error.

gcc blowfish.c -o blowfish -Llocation of libcrypt.so -lcrypto

or something very much like that.

- M
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: PKCS#7 without certificates??

[Michael Sierchio]

[EMAIL PROTECTED] wrote:

I've a problem. I need to cypher a buffer of bytes with pkcs7 format but 
I can't use certificates,i need encrypt using only a key or password.


I have searched but I do not find anything to do it.


Read the syntax for PKCS#7:

ftp://ftp.rsasecurity.com/pub/pkcs/ascii/pkcs-7.asc

For enveloped data:

EnvelopedData ::= SEQUENCE {
  version Version,
  recipientInfos RecipientInfos,
  encryptedContentInfo EncryptedContentInfo }

where

RecipientInfos ::= SET OF RecipientInfo

and

RecipientInfo ::= SEQUENCE {
  version Version,
  issuerAndSerialNumber IssuerAndSerialNumber,
  keyEncryptionAlgorithm

KeyEncryptionAlgorithmIdentifier,
  encryptedKey EncryptedKey }


Obviously for signed and enveloped data the sender needs a
cert, too.



__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: man in the middle attack over https

[Michael Sierchio]

[EMAIL PROTECTED] wrote:

I'd like to ask the group about a possible man in the middle attack over https.


What you've described (though see Viktor's post about what you didn't
really include in your message) is not MITM -- it's just a fake URL
scheme.   SSL v3.0 and TLS with server auth are not subject to MITM.

Regards,

Michael
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: certificate withou private key

[Michael Sierchio]

Yes. No. Maybe.

Such a question suggests some possible confusion.

A certificate is a binding of a keypair to an identity. 

While only the public key is contained in the cert, some proof of possession of 
the corresponding private key is required.

This usually requires a certificate signing request that includes a component 
signed using that private key.

The private key need not be present to the signer, and in fact must not be if 
non-repudiation is desired.

In the case of smart cards and embedded devices, the keypair and CSR are 
generated and the private key is never exposed.

Google the terms 'PKCS#10' 'SPKAC' and 'CSR'

- Michael
-Original Message-

From:  Mathias Tausig [EMAIL PROTECTED]
Subj:  certificate withou private key
Date:  Sun 2007 Sep 30 14:33
Size:  459 bytes
To:  openssl-users@openssl.org

Hy!

Is it possible to create a certificate with openssl without using the 
coresponding private key (which is stored in a smartcard) but with the public 
key only?

Mathias
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]



__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: use ssl for ssh transport layer (not proxy bypassing)

[Michael Sierchio]

David Latil wrote:

I have a somewhat bizarre project on my plate.  I have been tasked to come up 
with a secure proxy of sorts that uses SSH over SSL (I mean to actually encrypt 
SSH with SSL, not just tunnel through a proxy).  In the end, we would be using 
port forwarding over SSH for HTTP traffic.

being SSH is an application level protocol, I don't see why I could not replace 
the standard TCP connection that it uses with SSL.  Why you ask? the theory is 
if encryption via SSL is secure then if you doubly encrypt using SSH then you 
are doubly secure, supposedly there is some form of data compression built into 
SSH that may be benefitial, you could go through the firewall friendly port 
443, and you could use other higher level protocols through the SSH port 
forwarding feature.

I'm not very experienced programming with SSL, but I'm heavily researching the 
concepts at this stage, I'm a bit skeptical to say the least of the 
cost/benefits of this.

I sure would appreciate if someone could tell me if this is a bad idea and why, 
the more I know now at this time the better.


It would only be a bad idea if you were actually to implement it. ;-)

What's the problem you're trying to solve?  What set of requirements
is driving this (e.g. firewall traversal where SSH is not permitted,
even on port 443, but HTTPS is)?

Double encryption isn't always like belt-plus-suspenders -- sometimes
it's like pulling your zipper up, then down.  Google MITM (Meet in
the Middle) Attack.



__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: openssl verify signature with priv key?

[Michael Sierchio]

you verify a signature with the public key, and you sign with the private key. 


-Original Message-

From:  Janet N [EMAIL PROTECTED]
Subj:  openssl verify signature with priv key?
Date:  Mon 2007 Jun 25 13:17
Size:  351 bytes
To:  openssl-users@openssl.org

Hi there,

How do I verify a signature (dsa signature), with the private key using openssl?

Ive tried the following did not work (syntax erro), any help is appreciated!

openssl rsa -in sigcert.pem -noout -verify -key  userkey.pem

unknown option -verify
rsa [options] infile outfile
where options are
  

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: Certificates, users and machines

[Michael Sierchio]

Urjit Gokhale wrote:

It seems that you are making the common mistake of conflating authentication
with authorization.  Certs are useful in binding pubkeys to identities and
subsequently in verifying possession of the private key by being able to
perform decryption.

The SSL protocol has provision for client_auth, which means that the
server and client must each present a cert.  If this is the case,
need_client_auth is communicated in the handshake, along with a list
of DNs of CAs trusted by the server.  The client must present a cert
or cert chain which is rooted in one of those CAs.

 ...  is it necessary to

issue ONE certificate to EACH individual.


Yes.  The problem of granting access based on membership in a group
is an authorization problem.  This doesn't have anything to do with
certificates -- permissions and roles change independently of binding
of key to identity.  LDAP, flat files, /etc/group, etc.

You could have a hierarchy, with a subordinate CA for each role or
group, if you want to manage it that way.  I wouldn't.

- Michael
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: Certificates, users and machines

[Michael Sierchio]

Mouse wrote:

 I.e. for the sake of the argument identity
 Michael may have an attribute employee of Tenebras, and another
 attribute permitted access to dev repository A12.

Well, the Subject Distinguished Name should have the Organization,
but I strongly disagree with you if you think access permissions belong
anywhere in a cert.


The question of whether attribute certs are better or worse for
authorization than e.g. flat files is similar to whether cert-based identity
authentication is better or worse than e.g. LDAP-based one or flat files
e.g. Unix /etc/passwd.


Attribute certs are a lousy way to encode security policy.  You really
only need signed assertions if the relying party has no trusted
method of communication with the policy server (file/db/etc).  Revocation
is a pain, certificate status is a pain, and you've just multiplied
your public key computation load by a factor of three of four.
Much better to check whether the authenticated party has permission
to do what's requested at the time of the request.

Group membership is questionable -- the OU is certainly a kind
of group, but for the purposes of access control a party may
belong to many groups, and a robust policy might restrict access
to certain hours during certain days of the week.  If you
seriously consider this, then the idea of putting access controls
in certificates really looks absurd.

- Michael

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: how to extract signature from public key using openssl?

[Michael Sierchio]

Janet N wrote:

...   So we need
somehow to be able to get the rsa public key from the user certificate.


Assuming a DER X.509 cert, you just need to parse out the public key:

cert-SubjectPublicKeyInfo-SubjectPublicKey

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: Encrypt a Variable using PHP

[Michael Sierchio]

It's September - tomatoes are good, figs are ripe, grapes
are ready to harvest and school is back in session.

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: converting PKCS #7 data from BER to DER

[Michael Sierchio]

Benjamin Sergeant wrote:


I'd like to know how to proceed (is it doable) to convert a PKCS #7
data (made with PKCS7_sign, flag = PKCS7_BINARY | PKCS7_DETACHED;)
with several cert (the one from the signer) and a chain of cert, from
BER to DER encoding.


Is the decryption key present to sign the contents again after they
are rearranged by canonical encoding?  If not, then many of us are
counting on this not being remotely feasible. ;-)

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@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
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: how do i escape spaces in -subj (DN) arg to req?

[Michael Sierchio]

Richard wrote:


if, however i:

ssl req -subj /C=US/ST=NY/L=New York ...
ssl req -subj /C=US/ST=NY/L=New\ York ...

i get an error of:

unknown option York



what am i doing wrong?


Your problem is with your shell, not OpenSSL.  I'm reluctant to
say more -- I don't want to hand you a sharp implement and have
you cut yourself.

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: Openssl self-signed certificate verificatiion

[Michael Sierchio]

David Schwartz wrote:


For example, if you try to connect to 'www.amazon.com' and the resolver
resolvers this to '72.21.206.5', you want to get a certificate for
'www.amazon.com'. A certificate for '72.21.206.5' would not prove to the
user that he reached 'www.amazon.com' because an attacker could redirect the
DNS.

Verifying that you got the right certificate as opposed to a valid
certificate is outside the scope of what the SSL layer can do.


The key issue (pun intended) is possession of the associated private
key for the identity bound to the public key in the cert.  If the
party possesses it, they may be presumed (modulo key revocation, etc.)
to be the party indicated in the certificate -- no one else can perform
a successful SSL handshake.

Whether you like IP addresses or FQDNs is irrelevant.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: Hardcoded DH Params?

[Michael Sierchio]

Sreeram Kandallu wrote:

Hi All,

I'm building a p2p secure communication system where each user is
identified by a RSA key.
In such a system, is it ok to use hardcoded DH params compiled into the
application, or must i generate separate dh params for every user?


Hard-coded DH parameters (generator and prime) are fine.  I assume you'll
be negotiating ephemeral keys via some mechanism?
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: Hardware random number generator

[Michael Sierchio]

Wai Wu wrote:


I would like to know your opinions on commercial hardware random number
generators. Are they worth the money? How do they compare to the
/dev/random device? Thnx.


I've written extensively about this elsewhere.  The devices are properly
termed RBGs (random bit generators), and they produce very high quality,
cryptographically useful random bit streams.  The Intel chip on many
Intel Mobos has been extensively analyzed by Paul Kocher and others.

In summary, these are useful for stirring the entropy pool, but are
generally have maximum bit rates that are well below what a busy server
may need for random material, including ephemeral keys, nonces, padding,
etc.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: Regarding the IV in symertric encryption.

[Michael Sierchio]

Wai Wu wrote:
 
Do the Initial Vectors on both sides have to be the same? If they have

to be the same, we not only have to exchange the key, but also the IV,
No? 


Symmetric block cipher traffic contains the IV at the beginning of the
ciphertext.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: Regarding the IV in symertric encryption.

[Michael Sierchio]

Girish Venkatachalam wrote:

The IV is used only for decrypting the first block
since after that the first block serves as the IV for
the second block and so on.

To answer ur question, the IV has to be known at both
sides along with the key. 


There is no sound cryptological argument for not conveying
the IV as the first block of ciphertext.  It should be a
random nonce, and should never be repeated.  This argues
against using a shared value known in advance.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: Sequence of the handshaking

[Michael Sierchio]

Xie Grace Jingru-LJX001 wrote:


(1) what was just going on during the negotiation and security
connection setup? The sequence of the handshaking.
(2) Is the public key part of the certificate being passed to the
client?
(3) Did the server authenticate the client in this process? or there is
no authentication in this type of handshaking?
(4) What does the server do with the key generated (privkey.pem)? Is
this the private key? Does the client need to know about this key?
(5) Do both the server and client use the key to encrypt and decrypt the
data packets? Which key do they use?

Could you recommend any docs that explain all these.


http://wp.netscape.com/eng/ssl3/3-SPEC.HTM#7-5

from this doc:

http://wp.netscape.com/eng/ssl3/ssl-toc.html

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: SPKAC to PKCS#10 convert

[Michael Sierchio]

what can I do to convert a SPKAC request into a PKCS#10 ? After that
will I be able to generate a SPKAC certificate from PKCS#10 request ? 


You can't.

SPKAC is a signed pubkey and challenge. PKCS10 is a different
format of self-signed object.  You'd have to have the private
key present to generate either, and the ability to convert
between them would be proof that public key cryptography is
broken.

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: client side certificates

[Michael Sierchio]

Raymond Popowich wrote:

One thing that I'd like some clarification on.  Once I get this working, 
shouldn't there be a way for me to say I only want certain client side 
certificates to be able to connect to this web site?  Otherwise anyone 
with a client side cert can connect.  I'm sure I'm missing an important 
piece of information here and I just need to be pointed in the right 
direction.


If a server supports or requires client auth, it sends a cert
request that includes what type of cert is required, and a list
of DN's of recognized certificate authorities.  If you do not
present a cert signed directly by one of these, or a certificate
chain that has a cert signed by one of these, the handshake will
fail.

See the spec:

http://wp.netscape.com/eng/ssl3
SSL 3.0 Specification


5.6.4 Certificate request

   A non-anonymous server can optionally request a certificate from
   the client, if appropriate for the selected cipher suite.

 enum {
 rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4),
 rsa_ephemeral_dh(5), dss_ephemeral_dh(6), fortezza_kea(20),
 (255)
 } ClientCertificateType;

 opaque DistinguishedName1..2^16-1;

 struct {
 ClientCertificateType certificate_types1..2^8-1;
 DistinguishedName certificate_authorities3..2^16-1;
 } CertificateRequest;

 certificate_types This field is a list of the types of
   certificates requested, sorted in order of the
   server's preference.
 certificate_authorities
   A list of the distinguished names of acceptable
   certificate authorities.

   Note:  DistinguishedName is derived from [X509].

   Note:  It is a fatal handshake_failure alert for an
  anonymous server to request client identification.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: Password too long

[Michael Sierchio]

Nadav Golombick wrote:

What is the correct procedure if I come to a situation where the
password length is too big for the given buffer.


If this is a design question, then the proper thing to do IMHO
is akin to what's done for HMAC-MD5 or HMAC-SHA1 -- if the
passphrase exceeds the buffer length,  compute the SHA1
hash of the passphrase and use that as the passphrase.


__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]