Re: [openssl-users] OpenSSL vs GPG for encrypting files? Security best practices?

[Bear Giles]

FWIW I distrust encrypted drives using hardware encryption. This came out
just a few days ago:
https://thehackernews.com/2018/11/self-encrypting-ssd-hacking.html: Flaws
in Popular Self-Encrypting SSDs Let Attackers Decrypt Data.

On Tue, Nov 6, 2018 at 10:15 PM Nicholas Papadonis <
nick.papadonis...@gmail.com> wrote:

> Interesting.  How about this for a start?
>
>
> http://nickpapadonis.com/images-share/summerian-ancient-mesopotamia-ancient-lock.jpg
> http://nickpapadonis.com/images-share/anunnaki1.jpg
>
> http://nickpapadonis.com/images-share/summerian-Winged_Human-headed_Bulls.JPG
>
> On Sun, Nov 4, 2018 at 7:21 PM open...@foocrypt.net 
> wrote:
>
>> Hi Nick
>>
>> Have You tried The FooKey Method ? https://foocrypt.net/the-fookey-method
>>
>> Also,
>>
>> I will be sourcing public addendum's as addendum's to my submission into
>> the Parliamentary Joint Committee on Intelligence and Security [
>> https://www.aph.gov.au/Parliamentary_Business/Committees/Joint/Intelligence_and_Security/TelcoAmendmentBill2018/Submissions
>> ] regarding the committee’s review of the 'Telecommunication and Other
>> Legislation Amendment (Assistance and Access) Bill 2018' after the
>> Melbourne Cup. It will be similar to the open request for the Defence Trade
>> Control Act review performed by the former Inspector General of
>> Intelligence, Dr Vivian Thom.
>>
>>
>> https://foocrypt.net/independent-review-of-the-defence-trade-controls-act-2012-cth-call-for-information-for-submission-as-a-case-study-from-the-openssl-community
>>
>>
>> --
>>
>> Regards,
>>
>> Mark A. Lane
>>
>> Cryptopocalypse NOW 01 04 2016
>>
>> Volumes 0.0 -> 10.0 Now available through iTunes - iBooks @
>> https://itunes.apple.com/au/author/mark-a.-lane/id1100062966?mt=11
>>
>> Cryptopocalypse NOW is the story behind the trials and tribulations
>> encountered in creating "FooCrypt, A Tale of Cynical Cyclical Encryption."
>>
>> "FooCrypt, A Tale of Cynical Cyclical Encryption." is aimed at hardening
>> several commonly used Symmetric Open Source Encryption methods so that they
>> are hardened to a standard that is commonly termed 'QUANTUM ENCRYPTION'.
>>
>> "FooCrypt, A Tale of Cynical Cyclical Encryption." is currently under
>> export control by the Australian Department of Defence Defence Export
>> Controls Office due to the listing of Cryptology as a ‘Dual Use’ Technology
>> as per the ‘Wassenaar Arrangement’
>>
>> A permit from Defence Export Control is expected within the next 2 months
>> as the Australian Signals Directorate is currently assessing the associated
>> application(s) for export approval of "FooCrypt, A Tale of Cynical Cyclical
>> Encryption."
>>
>> Early releases of "Cryptopocalypse NOW" will be available in the period
>> leading up to June, 2016.
>>
>> Limited Edition Collectors versions and Hard Back Editions are available
>> via the store on http://www.foocrypt.net/
>>
>> © Mark A. Lane 1980 - 2016, All Rights Reserved.
>> © FooCrypt 1980 - 2016, All Rights Reserved.
>> © FooCrypt, A Tale of Cynical Cyclical Encryption. 1980 - 2016, All
>> Rights Reserved.
>> © Cryptopocalypse 1980 - 2016, All Rights Reserved.
>>
>>
>>
>> On 5 Nov 2018, at 10:35, Nicholas Papadonis 
>> wrote:
>>
>> Comments
>>
>> On Sat, Nov 3, 2018 at 5:56 PM Bear Giles  wrote:
>>
>>> > I'm considering encrypting a tar archive and optionally a block file
>>> system (via FUSE) using either utility
>>>
>>> Linux has good support for encrypted filesystems. Google LUKS.
>>>
>>
>>
>>> BTW a tar file starts with the name of the first entry. The 'magic
>>> numbers' are at offset 128 or so. However a compressed tar file will start
>>> with a known value since gzip, b2zip, and 7zip?, all start with their magic
>>> values.
>>>
>>
>> Does tar placing known data at a certain offset increase the probability
>> that someone can perform an attack easier?  They may already know the data
>> to decrypt at that offset and if the encrypted block overlaps, then the
>> attack is easier.
>>
>> Thanks
>> --
>> 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
>
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] OpenSSL vs GPG for encrypting files? Security best practices?

[Bear Giles]

> I'm considering encrypting a tar archive and optionally a block file
system (via FUSE) using either utility

Linux has good support for encrypted filesystems. Google LUKS. Most (all?)
distros allow you to install on an encrypted filesystem and with a little
bit of research you can have encrypted external drives and thumb drives. If
you dig into /etc/crypttab and udevadm you can even have encrypted drives
automount as long as LUKS already has your passphrase. (E.g., I'm a bad
bear because I used the same passphrase on my laptop and my thumb drives.)
It's not limited to passphrases - you could use a hardware device like
digikey or a file containing the secret key.

> I am also curious to why GPG is used for file based encryption when only
a single key is required.

As I recall PGP always uses a random session key* for the actual
encryption. with N copies of the key encrypted using a PBE passphrase, a
public key in the keyring, etc. That's how multiple people can decrypt a
file even though they don't share any keys. The data itself is chunked into
blocks and each block uses the same key but a different random salt.

I don't recall if also it prepends or appends random data. That's a common
counter to known-text attacks like knowing that a zip file always starts
with the same few bytes.

(* Well, "session key" when it's data-in-flight. I don't remember the term
when it's data-at-rest.)

BTW a tar file starts with the name of the first entry. The 'magic numbers'
are at offset 128 or so. However a compressed tar file will start with a
known value since gzip, b2zip, and 7zip?, all start with their magic values.
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Wrapper script for creating PKI with openssl Was: OpenSSL version 1.1.1 pre release 9 published

[Bear Giles]

This is a total aside but I prototyped a PostgreSQL extension that
implemented the PKI infrastructure using OpenSSL. (The OpenSSL C API...
shudder.) The database server already had it present, for SSL support, so I
could piggyback on that and not worry about export restrictions since
anyone that couldn't use OpenSSL couldn't run my extension either.

It was a hobby project and I largely dropped it for various reasons. Some
of it was specific to PostgreSQL (migrating away from OpenSSL) but a lot of
it was because there was already enough "good enough" solutions that the
perceived need had gone away. Many open source projects had documentation
for EasyRSA, but now they have integrated support for LetsEncrypt.

Anyway the point is that these type of projects have to be careful that
they don't invent a better mousetrap in a world where nobody is looking for
one. It's a fun project where you can learn a lot but it won't get much
traction unless it's a totally new approach. The existing solutions may
have flaws but most of the places where you need a CA already have
documentation on how to use EasyRSA, if not outright integration with a
solution.


On Mon, Aug 27, 2018 at 4:18 PM Hubert Kario  wrote:

> Changing Subject to help googlability :)
>
> On Monday, 27 August 2018 22:38:24 CEST Robert Moskowitz wrote:
> > On 08/27/2018 04:07 PM, Hubert Kario wrote:
> > > now, for generating testing certificates (and what's more important,
> the
> > > whole PKI) we are using this script to provide sensible defaults and
> easy
> > > way to generate certificates with just few options departing from those
> > > defaults: https://github.com/redhat-qe-security/certgen
> >
> > I will take a look at this.  It did not come up in my google searches a
> > year ago.  Guess just not asking the right question or github is
> > protected from google...
>
> definitely isn't; most of the visits on my other repos come from google
> (if
> github stats are to be believed)
>
> likely because similar scripts are not uncommon (e.g. OpenVPN ships with
> something similar) and this one is hardly well known, so it got delegated
> to
> "2nd page"
>
> > > to get a PKI you run those commands:
> > > source certgen/lib.sh
> > > x509KeyGen ca
> > > x509KeyGen server
> > > x509SelfSign ca
> > > x509CertSign --CA ca server
> > >
> > > The private key file will be printed by use of:
> > > x509Key server
> > > to get certificate file name you run:
> > > x509Cert server
> >
> > In testing situations I have been in, intermediate CAs, revocation, the
> > like are needed.
>
> it allows you to create arbitrarily complex CA structure, this is just the
> simplest example; there is also support for generating client
> certificates,
> OCSP reponder certificates, subject alternative names, etc.
>
> to get an intermediate you have to run the following commands:
> x509KeyGen subca
> x509CertSign --CA ca -t CA subca"
>
> the you can use 'subca' instead of 'ca' for signing the server cert:
> x509CertSign --CA subca server
>
> (the -t of 'webserver' is simply the default)
>
> revocation is not implemented yet, but as the tool keeps all the
> information
> about CA's signed certificates (it does use internally the `openssl ca`
> tool),
> adding it shouldn't be too hard... (and you can always do it manually)
>
> > Plus getting more interest in 802.1AR certs with vendors (can't get
> > certs to test out my product design).
>
> that I'm not familiar with
>
> > > (easy switches are also provided to get DER files or PKCS#12 files
> instead
> > > of the default PEM format)
> >
> > I will be interested to see how you handle DER, as I found cases where
> > the command line was broken.  Read my caveat section.  In some cases you
> > have to make the file in PEM then convert to DER.  Plus there is no DER
> > way to handle cert chains as was discussed here a year ago.  So I will
> > be interested to see how you handle cert chains non-PEM.
>
> The scripts internally keep everything as PEM files; DER, PKCS#12, etc.
> are
> for export only.
>
> If you want cert chains you have to create them manually. As I started to
> work
> on this script for the CA cross-signing, the built-in assumption was that
> there is no One True Cert Chain™. So it considers all CAs as stand-alone.
> If
> you want a cert chain you have to assemble it yourself.
>
> > > to get ecdsa certificate, you just need to change one of the above
> lines
> > > with x509KeyGen to have `-t ecdsa` specified. Want RSA-PSS
> certificate? do
> > > `-t rsa-pss`.
> > >
> > > See runtest.sh for other examples.
> >
> > I will take a look.
>
> Limited time offer! Call now and get Ed25519 support completely free! ;)
> https://github.com/redhat-qe-security/certgen/commit/
> 4b71e0a7d77929d944cc20f16f2ccf9514d6d94d
>
> > > It is compatible with all versions of openssl since RHEL-4 (so 0.9.7),
> if
> > > a
> > > given feature is supported in that version of openssl.
> > >
> > > (while ed25519 support is not yet there, it will be in few 

Re: [openssl-users] good riddance to PayPal

[Bear Giles]

Is it possible to set up two accounts, one US and one non-US, and then just
transfer funds between them? It would be more work than setting up a single
account but would eliminate a single point of failure risk.

Bear

On Fri, May 6, 2016 at 8:29 AM, Jakob Bohm  wrote:

> On 06/05/2016 15:26, Steve Marquess wrote:
>
>> On 05/06/2016 09:14 AM, Jakob Bohm wrote:
>>
>>> On 06/05/2016 13:45, Salz, Rich wrote:
>>>
 Consider having the non-U.S. person do the account setup too.
>
> Banks are as scared of US jurisdiction as crypto engineers.
>
 Yeah, we've done that.  Even to the point where one of the team was
 going to get on a plane to fly to the Isle of Mann.

 It's amazingly painful and difficult and so far not productive.

 If folks want to give OpenSSL money, mail a check or cash.

>>> I was thinking of the more simple solution of setting up
>>> the account in the same non-US bank where the team member
>>> does his other business.  Lots of this tends to get easier
>>> when the person is an existing customer and the bank is
>>> nearby.
>>>
>>> Each non-US team member presumably has at least one existing
>>> bank relationship and presumably knowledge and/or easy access
>>> to information on how to set up an independent legal entity
>>> in his/her own country.
>>>
>> Personal bank accounts, yes. But, we don't want to entangle OpenSSL
>> funds with any team members personal finances. Those funds need to be
>> held by an independent OpenSSL legal entity (of which there are already
>> several). Also keep in mind that most of my colleagues are hardcore
>> geeks best suited to wrangling OpenSSL code. I try to handle as many
>> paperwork hassles as possible to free them for that more important
>> activity.
>>
> I was trying to say that retail banks can be very helpful
> when an existing personal account holder wants to set up a
> business account with themselves as a signatory (but not
> owner).  Especially if the legal entity (new or existing)
> is also within their jurisdiction.
>
> Things like checking if the person is who his says he is,
> checking if the initial deposit is from a suspect source
> etc. become much simpler when the bank recognizes the
> person as someone they have worked with for years and the
> initial money source as an account that was the
> correspondent with past checks or other traceable
> transfers to/from that known person (all according to the
> banks own records).
>
> Throw in the prospect of earning transaction fees on an
> associated Merchant account, and motivation can grow
> further.
>
> Enjoy
>
> Jakob
> --
> Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
> Transformervej 29, 2860 Søborg, 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-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: [openssl-users] Developing CA with Openssl library

[Bear Giles]

I've written big chunks of a CA in both openssl and java (BouncyCastle). It
has definite benefits since it can be tightly integrated into an existing
infrastructure but does require a fairly deep understanding of both
concepts and implementation details. The actual key management is not that
hard to write once you have that basic knowledge.

However a CA is a lot more than just signing keys and that can be a lot of
work but I think that will be true regardless of whether you're doing new
development with the libraries or using scripts with the command line
program. The command line is fine for small needs but I would definitely
rather use the libraries (C or java) if I had it sitting behind a web or
microservice.

Finally I should point out that Amazon has just released an X.509 key
management system as part of Amazon Web Services. I haven't had a chance to
look at it but it might be easier to implement a front end to it.

Bear

On Wed, Mar 2, 2016 at 11:24 PM, lists  wrote:

> On 03/02/2016 09:36 AM, thirumalkumarkanakur...@bel.co.in wrote:
>
>>
>> Dear users,
>>  I want to develop my own CA with openssl library with all the CA
>> functionalities like Key generation,Certificate creation,Certificate
>> Revocation List creation,Certificate revocation and certificate
>> verification.in Order to do so i am struct with the following questions
>>
>> 1. currently i am using openssl_1_0_1 stable version. With this version
>> is it possible to perform the above operations.
>>
>
> Yes, but it's a lot of code to write if you plan to use the library.
>
> 2. Will above mentioned version provide full CA CRL functionalities.
>>  please help me  with your valuable suggestions and solutions. Thanks in
>> advance.
>>
>>
> For what I know, all of it is there, too.
> But really consider using OpenSSL-based open source products or at least
> openssl command line tools where possible, otherwise it is just as answer
> (1): there is a lot to do!
>
>
> Regards
>> Thirumal Kumar Kanakurthi
>> Member (Research Staff)/NWS Group
>> Central Research Laboratory(BEL).
>> Bangalore.
>> Mobile:+918050469976
>>
>
> --
> 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

[openssl-users] can I parse PKCS8 file and decrypt it later?

[Bear Giles]

Two questions actually.

I've been able to read and write most objects using both the PEM bio and
i2d/d2i functions. I know I can write an encrypted PKCS8 file
with PEM_write_bio_PKCS8PrivateKey().

How do I read encrypted PKCS8 files? I can read unencrypted files with
PKCS8_PRIV_KEY_INFO but have been stumped by the encrypted file. Obviously
'openssl pkcs8 ...' can do it but maybe I'm overlooking a source of
documentation. Otherwise it's a dive into the source code.

Second question - can I parse encrypted PKCS8 files without decrypting it?
I know the traditional keys have to be decrypted (and thus parameter-less
readers can't use encrypted files) but I thought PKCS8 was a container and
it was possible to parse the object without the password. Does this involve
X509_SIG?  I noticed that the i2d/d2i PKCS8 functions work with X509_SIG
objects.

Thanks,

Bear
___
openssl-users mailing list
openssl-users@openssl.org
https://mta.opensslfoundation.net/mailman/listinfo/openssl-users

Re: Tomcat vs. OpenSSL CA?

[Bear Giles]

Have you checked the conf file for the openssl ca?  I haven't looked at 
it in a long time, but I think you can specify whether an element is 
required or optional in it.


Bear

Josh wrote:


Howdy Folks,

I am trying to pretend to be a CA with OpenSSL.  I have done this 
before and generated certificates to use with private keys on Apache 
and IMAPs. However, this time around, I need to pretend to be a CA 
that signs Tomcat certificates.


There is a minor problem.  When I generate a Tomcat based key, like so:

keytool -genkey -alias myalias -keyalg RSA -keystore mykeystore
keytool -certreq -keyalg RSA -alias myalias -file certreq.csr
-keystore mykeystore

...the resulting CSR does not include the email address.  OpenSSL 
refuses to sign a CSR that does not have an email address.  I've 
looked around for a bit to find out how to add the email address (and 
how to get OpenSSL to ignore tha lack of an email address) to no avail.


Has anyone done this?

Cheers,
-J
__
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: 0 bit encryption?

[Bear Giles]

You don't stand to gain much by not encrypting and only authenticating.
  
Encryption and authentication are very different things. They're related 
since encryption without authentication leaves you open to 
man-in-the-middle attacks, but there are plenty of situations where you 
just need authentication and message integrity.


Don't forget that message encryption may be locally illegal or 
prohibited. Some countries outlaw encryption entirely, and large 
organizations may require all email traverse internal VPNs in the clear. 
In both cases correspondents may still want to have confidence that the 
remote system is who it claims to be.


(Aside: why would an organization insist on internal cleartext? One big 
cause is sexual and racial harassment complaints. Settlements routinely 
require the organization to monitor all email for offensive content.)



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

Re: 0 bit encryption?

[Bear Giles]

Victor Duchovni wrote:

On Sat, Nov 18, 2006 at 11:13:45AM -0500, Brian Thompson wrote:

  

This applies to encrypting email content (S/MIME, PGP, ...), but not to
use of TLS, which leaves the delivered email in the clear.
  

According to the sendmail docs:
privacy/confidentiality: the transmission of an e-mail between a client 
and server utilizing STARTTLS can not be read and retranslated into 
plaintext provided a sufficiently secure ciphersuite has been negotiated.





This is silly. Note the word *transmission*. Email supervision does not
require clear-text transmission, because it is done against stored data,
not eavesdropped network packets. Over and out.
Hardly. You're trying to treat potentially legal problems as purely 
technical ones. Organizations hauled into court can't always say trust 
me, and organizations may want to quietly use outside consultants if 
they're investigating/monitoring their own IT departments.


Then there's the whole cryptography is illegal in the People's Republic 
of Freedonia factor

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

Re: Security Question

[Bear Giles]

I don't have the details at hand, but look at perfect forward secrecy 
in SSL and TLS, Rescorla.


Sreeram Kandallu wrote:


Hi All

Is it possible to decrypt a recorded SSL session, if the attacker gains
access to the RSA private keys at a later point in time? If yes, what
would be the best way to avoid this?

Thanks in Advance!
Regards
Sreeram

 



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

Re: Security Question

[Bear Giles]

Related note: you can explicitly request re-keying at any time, and 
should do it periodically on long-term connections. That makes analysis 
even more expensive since there's less data and less payoff.


Victor Duchovni wrote:


For all these ciphers the attacker has to brute force the symmetric key,
 



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

Re: Encrypt in Java and decrypt in Openssl (and vice versa)

[Bear Giles]

Dominique Lohez wrote:

This could be due to the fact that in JAVA character are coded in 
UNICODE ( Each character uses 2 bytes)
While in C each character is coded with only one byte for each 
character. This could be checked from JAVA by squeezing

the first byte of each character.


I would have to check the APIs to be sure, but I thought the Cipher 
class took byte[] instead of char[].   You have to specify an encoding 
to go from chars to bytes, but any of the ISO-8859s would give you one 
of the standard enhanced ASCIIs.


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

Re: openssl on arm

[Bear Giles]

sun yingming wrote:

 I'm now trying to realize a SSL connection on embedded system.But I
 had some problems in the beginning.how can i compile the OpenSSL in
 arm-linux-gcc? Simple by changing the gcc to arm-linux-gcc in the
 Makefile?
 But i got the error as in the ScreenShot.png.
 how can i do with this ?

You have to build a full cross-compiling toolchain. For instance, if
you're running on an i386 (PC) machine your compiler and linker normally
produces i386 libraries and executables. You need to rebuild the
compiler so it runs on an i386 but produces arm libraries and executables.

Have you looked at the NSLU2 project? (nslu2-linux.org) It has a
makefile that will build a cross-compiling toolchain for arm _and_ use
it to build a complete embedded Linux system ready to be flashed.
Actually several scripts - there are two early efforts (SlugOS and
UpSlug, iirc), and now two Debian efforts. If nothing else it should
have the OpenSSL library somewhere in there -- everyone uses either
dropbear or openssh.

P.S., mine is great. I've thought that it would be an interesting CA.
Extremely small and low power so it could be physically secured
anywhere, you could store routine files (e.g., CRL) on one USB stick and
high-value keys on a second USB stick normally kept secured, and o on.

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

Re: Chicken and egg issue

[Bear Giles]

WebSpider wrote:

How can I make the new node (A) send an encrypted request to the
already existing node (B) while node A does not have any public
key/certificate information about the already existing node (B), and
still make sure that I am actually talking to B, and not some
Man-In-The-Middle ?


Take everything I saw with a huge grain of salt, but as you said the 
expects may be occupied at this time of year.


(A) encrypted communications isn't a problem.  The certs are used for 
authentication (How do I know 'Bob' is really Bob?), not key exchange. 
  Each party can offer a cert, it's up to the other party to decide 
whether to ignore it, log it, or verify it.


(B) authentication, and hence avoiding man-in-the-middle, requires 
either prior knowledge of the trusted certificate or the entire 
certificate chain back to a trusted root.  You would use the CRL to 
verify that a valid certificate hasn't been subsequently revoked.  (You 
should also check the expiration time.)


I don't use OpenSSl enough to recall how to do each, but you could 
probably find information on the first by looking up 'anonymous' sessions.


HTH

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

Re: Authentication

[Bear Giles]

Mark wrote:
 I noticed a function X509_subject_name_hash().  Will that give a unique
 reference to a certificate?  It seems to ;-)

No hash can be guaranteed to be unique.  Issuer and serial number
should be, but of course you need to exercise some intelligence here.

You can use the subject hash (or a subset) to perform quick
lookups.  E.g., if you have a large number of certs indexed by
their SN hash, you can quickly determine that you don't have the
specified cert or find a few possible matches.

In practice?  A 20-byte hash will almost certainly be unique.
What's your risk tolerance?

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

Re: Authentication

[Bear Giles]

Mark wrote:
No hash can be guaranteed to be unique.  Issuer and serial number
should be, but of course you need to exercise some intelligence here.

 In that case I'll use the Issuer and Serial number.  Thanks.

As I said, just remember to use some intelligence.  Verify the
issuer, be prepared for the case where a clueless CA issues the
same serial number (which is definitely an error, but how will you
handle it?), etc.

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

Re: Authentication

[Bear Giles]

Mark wrote:
 Are there any additional steps necessary to verifying the issuer
 apart from the normal peer authentication and a string compare of
 the issuer name?

Just follow the certificate chain back to a trusted root.  Anyone
can forge a certificate chain, but they won't be able to get back
to a trusted root.

If you don't do this a malicious party could substitute his cert
for a good one and/or prevent a legitimate user from providing her
own good cert.

Bear

P.S., remember that the serial number is an arbitrarily long
numbers/strings.  Some CAs (Verisign?) appear to use cryptographic
hashes as their serial numbers.  Others use a modified timestamp
(e.g., MMDDHHMMSSxx).
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: Authentication

[Bear Giles]

Mark wrote:
 It is likely that we would want to embed some additional data in
 client certificates to further enhance security.  For example we
 may wish to include a (list of) IP address(es) that the client
 can connect from and reject those not on the list.  Alternatively
 we could create a database of clients and their IP addresses on
 the server and perform a lookup based on some unique identifier
 in the client certificate.  I would be greatful for ideas on
 the way to go here and how to implement it.

It seems like a Really Bad Idea to key to IP addresses in the
certificate.  They can not only change, they're often outside of
the client's control.  Fully qualified domain names are much
better.  Server certs use their FQDN as their Common Name.

On the server side, why not maintain a database of clients and
FQDNs or IP addresses?  What you gain in flexibility should more
than offset the increased complexity in the code.

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

Re: Authentication

[Bear Giles]

Mark wrote:
 What feature of a certificate could I use to provide an unique key
 in a database table for this?  How could this be extracted in a
 program?

The Common Name.  You could use it as an LDAP key, convert it to a
string and use that a key into a database, etc.

One important nit -- you want to verify the issuer and should
actually check (issuer, common name) instead of just your common
name.  It reduces to the CN alone if you only accept your own
certificates.

If you don't check the issuer you're vulnerable to black hats
generating their own certificates and using them to gain access.

BTW, Ted was referring to the separation between authentication
(who are you) and authorization (what can you do).  It's a
standard security practice and you should think very hard before
combining the functions.  Checking IP address would be part of the
authentication step.

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

Re: Authentication

[Bear Giles]

Peter Sylvester wrote:
 Bear Giles wrote:
 The Common Name.  You could use it as an LDAP key, convert it to a
 string and use that a key into a database, etc.

 You probably mean the Subject DN.

Yes.  oops.  I need to get better at proofreading. :)
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: question about data transfer

[Bear Giles]

When you say data stream, how much data are you talking about?
If it's occasional data (e.g., updated every 5 minutes) it would
probably be easiest to use a HTTPS client using a post form.
That lets you use a standard web server on the other end.  One
less thing to worry about.

Another possibility is secured email, SMTP + TLS.  If you have a
relatively smart sensor (e.g., an embedded Linux system) you could
 write a straightforward mail client that sends mail to the local
mail server (on localhost).  You can then let
sendmail/postfix/exim/whatever forward the mail to your system
with a secure connection.  Again, one less thing to worry about.

If it's close to continuous you should probably establish your own
network connection instead of trying to piggyback on an existing
service.

In any case you need to think about how you will handle network
connectivity problems... and you will have dropped connections,
high latency, etc.  Can you drop the data on the floor?  If not
you'll need to have an accurately timestamped data queue.  That's
not hard to do (hint: NTP), but it will drive the design.

Bear

sun yingming wrote:
 I am trying to use ssl to secure a persistent data stream which
 is read form some sensors outside, and transfer it to a fixed
 pc on the interent. The most common use of ssl is Https,but i
 am confused that can https realize this application? i mean ,
 as i know ,the Https is always works in Browser/Server mode ,is
 it realizable to use Https to transfer a persitent data
 stream,or i should choose other protocol like ftp?
 
 anyone who can help me is thankful
 
 Sun Yingming

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

Re: Question on a good attribute for local information

[Bear Giles]

Issuer DN and serial number are unique.  In practice you'll need
to consider whether you'll be dealing with anyone other than
competent CAs (organizations and individuals).  openssl ca is
great but it's trivial to produce multiple certs with the same
issuer DN and serial number.

Bear

Phil Dibowitz wrote:
 We'd like to tie all of our certificates to a unique identifier in a
 DB... is there an attribute out there, perhaps in the PKIX extensions or
 x509v3 extensions or somewhere else that would be a reasonable place for
 this?
 
 Thanks,

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

Re: Crypted Message trasfer across OS

[Bear Giles]

First a question for you.  Are you BASE64-encoding the buffer?
It's a modest pain but that encoding was designed to ensure
reliable transport of binary data between systems.

How?  The decoder isn't affected by systems that convert a newline
into a carriage-return/newline (e.g., when you transfer a file in
the default mode in FTP).  It isn't affected by protocols that
drop the top bit.  It can be reliably delivered by all of the
standard protocols.

Bear

Dorairaj B - CTD, Chennai. wrote:
I am transferring a AES encrypted buffer by writing to a file in Windows
and then trying to decrypt the buffer from the transferred file in Linux.
Though i use the same key both sides, the decryption does not work.

I use the following:

windows 2000 professional with openssl-0.9.8a
Linux 2.4.20 with openssl-0.9.8a
Used fgets, fputs for transferring contents from buffer to file.

I suspect doing the file operation would add '\0' at the end and might
cause problems. 

Is there a standard method of transferring the encrypted message from
Windows to Linux and viceversa?
Any help on this would be useful.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: printing encrypted strings

[Bear Giles]

There's a BIO that handles BASE-64 encoding and decoding.  It
makes the files much friendlier to naive editors and operating
systems since it forces the contents to standard ASCII characters
and you aren't dealing with \xxx encodings in your editors.  Does
DOS/Windows still need that silly explicit binary vs character
mode on fopen()?  If it does, it could be something as simple as
LF - CRLF coercion.

The only other question is whether you're sure you're reading and
writing all of the available data, using an element size of one,
etc.  All the boring standard stuff when using fread()/fwrite().

Bear

Sheehan, Tim wrote:
 I'm working in C.
 
 I'm actually using the AES 256 algorithm. It has been bolted in
 to the SSL like DES(and other enc algs).  The encryption piece
 appears to be working well.  I can cipherdecipher without any
 issues.  It is when I store that encrypted string to a file. 
 The file being written is opened with fopen and then fwrite 
 and fread are used to write  read.  
 
 When I write it out to the file is shows up in a binary format eq.
 
 \326\34368^H\316f]\234^E\371^C\342\246\217d=\341?^R\310\237[3^\:\236\241\
 206\243
 
 Then when I am reading it back, the unique characters are interpreted
 incorrectly.
 T
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: Java bindings

[Bear Giles]

I looked at this a while back, ultimately decided to go with a
pure java implementation (BouncyCastle, iirc) since it was
sufficient for my needs.

Anyway, you can use JNI to create a binding between the OpenSSL
library and Java.  This is a C layer and your main hassle will be
ensuring that you have the memory management down cold.

On the java side, you should find a copy of Java Security
(O'Reilly) or comparable text and implement the full SPI so you
can use the standard java classes.  (You'll need to list yourself
as a crypto service provider in the runtime configuration file --
see the book for details.)  In J2SE you'll want to look at the
javax.crypto.*Spi classes, I'm not sure if they're the same in J2ME.

You could implement your own interface, of course, but that would
prevent you from using third party libraries written to the
standard interfaces.  I think it's also much more risky from a
project management perspective - how stable will your interface
be, how will changes propagate through the rest of the software,
how long will it take new staff to come up to speed, etc.

Bear

Chris Gray wrote:
 Hello all,
 
 I'm looking for ways to use OpenSLL from Java on an embedded platform (J2ME 
 CDC), in order to be able to take advantage of the hardware crypto 
 acceleration which is available on that platform. Does anyone out there have 
 experience of this? Google comes up with a number of projects:
  - JavaSSL: link (from http://www.openssl.org/related/apps.html) is broken.
  - ITISSL: server http://sponsor.iti.informatik.tu-darmstadt.de/itissl/ is 
 not 
 reachable.
  - SSLava  (from Phaos): but does this useOpenSSL? Looks like not.
  - PureTLS + GoNative: looks hopeful, but is it maintained? The web page 
 mentions a serious problem with SHA-1 which will be fixed in the next 
 version ...
 
 BTW what is GSS-API (RFC 2853), which also turned up in my searches? I know 
 it 
 stands for Generic Security Service, but where does it fit into the puzzle?
 
 TIA,
 
 Chris
 

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

Re: certificate embedded into the executable

[Bear Giles]

Dr. Stephen Henson wrote:
 Depends on whether you want it embedded in the executable after it has been
 linked or at compile time, i.e. embedded in a C source file.

I think this is slightly off, but at link time (using the gnu tool
chain) you can use:

  ld -b binary -r -o root.o root.pem

then in your program

  extern const char _binary_root_pem_start[];

will contain the contents of 'root.pem'.  The object table
includes _binary_root_pem_size and _binary_root_pem_end but
it's too early in the morning to figure out why I'm having trouble
accessing those values.

There should be something in the archives in mid-late 2002 (iirc).

 If this is used for any kind of security you might consider obscuring the
 certificate in some way, to avoid simple replacement with a hex editor. Though
 a determined and knowledgeable attacker wont be so easily foiled.

A determined and knowledgable attacker can subvert anything that's
not in hardware.  Pulling a cert from a server isn't that much
harder to break given that it's trivial to set up a local DNS
server that will redirect queries to the attacker's own server.
(Or to simply use the same editor to replace your URL with their
own.)  Another attack is to attach to the process, stop it after
the cert has been loaded, then replace that cert with the attacker's.

One positive thing: if you're operating at this level it's trivial
to use encryption and hashing to hide the cert and verify it has
not altered.  It's not perfect and you'll still need to embed an
encryption key.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: certificate embedded into the executable

[Bear Giles]

David Schwartz wrote:
 %.h: %.pem
   xxd -i $  $@

That's compile time so it's not quite as flexible as the link time
command.

Why does this matter?  You might have a situation where the source
code is managed by one group without access to the PKI objects,
and the PKI objects are managed by another group without access to
the code.  That's a moot point with the full GNU toolchain but
they might only be provided with a stripped down linker.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: certificate embedded into the executable

[Bear Giles]

David Schwartz wrote:
Dr. Stephen Henson wrote:
 
A determined and knowledgable attacker can subvert anything that's
not in hardware.

   I think this is a very strange thing to say. If he has access to the
 hardware, he can subvert it too. If he doesn't have access to the hardware,
 how can he subvert the software?

Software is exploited or subverted all of the time without access
to the physical hardware.  You don't even need a shell account on
the system if there's a remote exploit.

Most, but not all, hardware can be compromised if you have
physical access.  Hardened equipment is not cheap.

Pulling a cert from a server isn't that much
harder to break given that it's trivial to set up a local DNS
server that will redirect queries to the attacker's own server.
  
   So sign the cert. No hardware needed.

How do you verify it's ultimately signed by the right certificate?
 You need to get the root certificate from somewhere.

(Or to simply use the same editor to replace your URL with their
own.)
 
   Sure, if you have access to the software. If you have access to any
 security scheme, you can simply disable the scheme.

The original context was Dr. Henson's well-grounded observation
that anyone with a hex editor could easily change an embedded
certificate.  Once you have access to the software then anything
in it, or its environment, can be changed at will.

   If you have that level of control over the process, you can make the
 process do anything you want, but you could just do what you wanted anyway
 with that level of control over the system. So what do you need the process
 for?

   If someone wants to alter the certificate that secures their own 
 machine,
 why should I care? You can certainly break things that you are allowed
 access to.

Reread what you just wrote - what if the certificate is used to
verify credentials provided by others to gain access?  (BTW don't
assume it's only protecting a machine.  Maybe this is part of an
application that controls access to extremely expensive or
sensitive material.)  Give me the ability to reset the root
certificate and I have an unlimited pass throughout your system.
Potentially worse I can deny access to your legitimate users.

Another example of a certificate as a credential - license keys.
Maybe we're talking about software that normally sells for $10k,
but also has a $100 student version with limited functionality.
Same software, but I think most of us can see how the company will
make a distinction between the guy who paid nothing, the student
who got an educational version, and the company that bought a full
license.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: certificate embedded into the executable

[Bear Giles]

C L wrote:
 Theoretically it's possible to embed certificates into a Windows and
 Linux executables - not sure about other architectures though.

I don't recall the exact invocation off the top of my head but you
can create a make rule that's something like:

  cert.o: cert.pem
 ld -o $@ (flags) $

and that will convert the specified PEM (or DER) files into data
segments with external symbols providing the caddr_t (char *) and
size.  Something like const char * cert_data and size_t cert_size.
You can then declare the symbols as 'extern' in your source code
and treat it like any other buffer loaded from disk.

Alternately you can explicitly include the cert as a constant
string.  It works but requires you to manually maintain that code.
 The linker will always use the current files.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: need function to get cube root

[Bear Giles]

Anirban Banerjee wrote:
 Hi everyone,
  Can someone please let me have a pointer to how I may obtain a cube root of 
 a BIGNUM,

Hopefully others will have better ideas but one possibility is to
use Newton's formula.  I'm not sure what it is with cube roots but
it's probably something like:

   y = guess;
   while (error too large)
  y = (y + x/y/y)/2

For the initial estimate it's good enough to create any number
with one third of the number of bits in the number you're taking
the cube root of.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: Approximate memory ratio for encrypted and non encrypted data

[Bear Giles]

Nadav Golombick wrote:

Hi,
 Is there an average ratio to encrypted -- non-encrypted data?



It should be 1:1.

HOWEVER, it's more complex when you're talking about a complete 
system.  Data should usually be compressed before encryption and 
there's normally framing and other added in the encrypted stream. 
 One drops the ratio, the other increases it.


Further complicating this is the possibility that a really 
paranoid person will include frames containing random data. 
(There will be some hidden marker indicating that they should be 
ignored, of course.)  It's hard to guess what's in an encrypted 
file if they're always padded to a multiple of a megabyte or two.


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

Re: using openssl and sunjce, encrypt same text,get different result

[Bear Giles]

I don't know about the RC4 problem, but EVP_des_ede is triple DES. 
 I thought JCE DES is single DES.  (Single DES is depreciated 
now, BTW.  I thought there were also questions about RC4.)


I also wonder if you're generating the same key, but I'll leave 
the nuances of the key generation procedures to others.  (E.g., I 
thought the FIPS standard encrypted the key with itself and didn't 
use a hash.  If both procedures should use a hash, how do you 
specify it in the JCE?  Etc.)


Bear


cellecial wrote:

Hi,
I need to encrypt data using C+openssl,then decrypt data using JAVA+SUNJCE.
When I encrypt the same plaintext using openssl and sunjce,
I found the two ciphertexts  are different.
I tried two algorithms:EVP_des_ede() / DES ,EVP_rc4() / RC4,
but the results are all depressing.

I googled a post in which someone said,you can use open ssl to encrypt the data and 
decrypt the same using java (any JCE implementaions) .Provided you have to use same 
algorthim with correct pading and initialisation vectors .
I think this is my problem.Maybe I don't know the correct padding or iv.
So,can anyone help me to solve this problem?
Thank you very much.

Here is my main code.

/* C+openssl encrypt key is parameter[strref] such as strref=123456; */
int M_encrypt(unsigned char *in,int inl,unsigned char *out,int *outl,
unsigned char *strref,int strrefl)

{
EVP_CIPHER_CTX ctx;
unsigned char ekey[EVP_MAX_KEY_LENGTH];
unsigned char eiv[EVP_MAX_IV_LENGTH];
int tlen,flen;

EVP_BytesToKey(EVP_des_ede(),EVP_md5(),NULL,strref,strrefl,1,ekey,eiv);


EVP_EncryptInit(ctx,cipher,ekey,eiv);
EVP_EncryptUpdate(ctx,out,tlen,in,inl);
flen=tlen;
EVP_EncryptFinal(ctx,out+flen,tlen);
flen+=tlen;
*outl=flen;

return 0;
}

/* JAVA+sun jce, encrypt key is parameter[key]byte[] key=new 
String(123456).getBytes(); */
public static byte[] encrypto(byte[] input,byte[] key) throws Exception{
SecretKey deskey = new javax.crypto.spec.SecretKeySpec(key,DES);
	   
	Cipher c1 = Cipher.getInstance(DES);

c1.init(Cipher.ENCRYPT_MODE,deskey);
byte[] cipherByte=c1.doFinal(input);
	
	return cipherByte;

}



__
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: Recommended SSL Books...

[Bear Giles]

[EMAIL PROTECTED] wrote:
Thanks for all the responses -- Network Security using OpenSSL it is and 
I expect it will be of the same high quality as other O'Reilly Books I 
own.


I haven't looked at that book but for a long time THE book was 
SSL and TLS: Designing and Building Secure Systems by Eric 
Rescorla.  He's written several SSL implementations (both 
commercial and free), and is the author of several RFCs related to 
SSL.


I wasn't exactly uninformed about crypto, but I learned a lot from 
 these books.


It may come down to the problem you're trying to solve.  Are you 
trying to maintain an application or code to an existing protocol? 
 In that case the O'Reilly book is probably best.  If you're 
trying to design a secure system from scratch, the Rescorla book 
is probably better at first since it will drive your design.


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

Re: Hard-wired CA-cert in source code?

[Bear Giles]

Richard Levitte - VMS Whacker wrote:

In message [EMAIL PROTECTED] on Wed, 20 Nov 2002 11:29:26 +0100 (MET), Andreas Jusek [EMAIL PROTECTED] said:

a.jusek Since the connection is always established to the same
a.jusek server, which is certified by an internal CA, I'm thinking
a.jusek about hard wiring the CA's cert into the clinet's code. Does
a.jusek anyone know how this can be done? How can I put the contents
a.jusek of the file into an X509 object in the source code? Does
a.jusek anyone have a better idea how to cope with this situation? 

openssl x509 -C -in infile.pem


A more flexible approach is to embedded the PEM object (of ANY object) 
as a C string:

  static const char cert[] =
   begin certificate \n\
  MII\n\
  aaa\n\
  a==\n\
   end certificate \n;

and use BIO *BIO_new_mem_buf(cert, sizeof(cert)) to set up a buffer that 
can be used with any of the standard tools.

This allows you to embedded any object - even private keys.  In the 
latter case you would want to embed an encrypted key and prompt the user 
for the passphrase.

BTW, I normally use this technique to support things like ephemeral 
keys.  I try to load a user-specified file (e.g., dsaparams.pem), but if 
none are specified I'll fallback to hardcoded values instead of 
disabling ephemeral keys.

Bear

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

Re: Is a https proxy possible?

[Bear Giles]

 Presumably the point of this exercise is to be able to analyze normally
 encrypted traffic.

That's what I thought when I first read your problem description.

IMHO, you're going at this the wrong way.  Set up a second box running
snort.  Set it up to read the encrypted traffic... and use a decrypting
engine.  (Something like ssldump - I don't know for sure that snort
has this yet, but you could always hack something together from the
ssldump source.)  You'll require the server's private key to decrypt
the traffic, but that shouldn't be a problem if that really is your own
secure web server. :-)

The benefit is that snort can log as much or as little as you want.  Once
you have the monitor set up, it's just a matter of deciding what to log
and how to set up subsequent queries to the database backend.

One possible gotcha is that I'm not sure ssldump works with servers
set up for perfect forward secrecy.

THAT SAID, I find this rationale very strange.  I've given this some
thought, but only because I was trying to determine whether it was 
possible to set up a snort-based NIDS to monitor encrypted traffic for
an indication that I would want to drop the connection at the firewall.
If you just want to know what's going to/from the web server, it makes
a lot more sense to instrument that server than go through the hassles
of setting up a sniffer.

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

Re: free Certificate Authority

[Bear Giles]

evilbunny wrote:

Be interesting to have a standard cross verification scheme/policy
between free efforts where the data is sent and then some rules
applied against it if it's 98% the same or something ok it...


I was thinking about cross-certification last night, but I'm not sure if 
it makes business sense.  On the other hand there's a lot to be said for 
 having multiple cert stores, so if one site is down the cert can be 
verified at another site.

May not be practical *shrug* and also 1 site may not agree with how
another treats the policy of it's certificates etc...


That's the problem with cross-certification.  If you trust one site that 
fully, you're trusting every other site they trust.  The web of trust 
sounds great in theory, but in practice trust isn't transitive. 
Otherwise we would all be using rsh instead of ssh.

(Okay, there were a number of other problems with rsh.  But the 
transitive nature of trust assumed in the model was one of its most 
intractable problems.)

Bear

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

Re: free Certificate Authority

[Bear Giles]

evilbunny wrote:

Interesting idea... Only problem is the bank doesn't verify the name
electronically as far as I'm aware... Least none of the payment
gateway's I've dealt with in the past...


(I was planning to charge $10, but I am also planning to offer personal 
server certs if you have a $10 cert.)

There's no requirement that you have your legal name on your credit 
card.  I've gotten them in aliases before, most banks really don't care 
what you have on your card as long as you pay your bills.

(The gory details?  My parents were not cool, but I had Bear on my 
credit cards and checks years before I broke down and had my name 
legally changed.  It's much more common for aliases to occur because of 
marriage and divorce.)

HOWEVER, I thought the credit card processing centers could verify that 
the name and address provided on the order was identical to the card's 
billing address.  Like verifying email addresses by requiring 
confirmation through that address, it really doesn't prove anything but 
it's more than enough for most casual purposes.

In addition, if you charge a reasonable amount ($10+) you can easily 
have an automated process that prints out acknowledgement forms and 
physically mails them to the nominal cert holder.  You have to stuff 
envelopes, but with window envelopes and a postage meter it won't cost 
more than a buck or two to send a letter to everyone confirming that a 
cert was requested (and granted) in their name and if this was erroneous 
they should contact the CA at some website.  If the mail is returned, 
revoke the cert but keep the money. :-)



One other note - I don't think you can save the full credit card info 
once the transaction has cleared.  Merchant agreements, state laws, all 
tend to frown on this.  You should be able to save the first four digits 
(which identify the issuing bank - not because you actually store these 
digits, you see, but because that happens to be the BankID in your 
database!) and the last four digits (which are now the traditional way 
of identifying a customer' card).

Bear

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

Re: free Certificate Authority

[Bear Giles]

Xperex Tim wrote:

I don't really see the value of free certificates.  If they are free that means that the CA can't
be doing any identity checks.  So any schmoe can get a certificate with your name on it and claim
to be you.


Even a free cert can easily verify that the email address is valid 
enough that somebody was able to use the acknowledgement key sent to it. 
That doesn't prove much, but it's more useful than you think.

As for any schmoe can get a certificate with your name - so what?  I 
live in a college town, do you think it would be hard to get a fake ID 
with your name and address on it?  With a bit more money, I could drive 
into the nearby large city and get a pile of papers showing that I'm 
you.  One of the unintentional consequences of cracking down on illegal 
immigrants has been an explosion in identity theft and forged documents, 
and the bad guys you want those identity checks for can cover their 
tracks better than most checks can uncover.

Even on the corporate side, it's not that hard to get a list of 
corporate officers from the SEC and create a forged letter authorizing 
some action.  That's how Verisign was tricked into issuing a Microsoft 
cert to an unauthorize person (IIRC).

The bottom line is that identification of people with strong reasons to 
remain mis-identified is, and will always be, a hard problem.  Even a 
$300 cert fee can only give you a modest comfort level that the other 
party, if they really are bad guys, aren't totally incompetent bad guys. 
But this doesn't mean that minimal checks (e.g., verifying that the 
subject can receive mail at the address provided) are worthless.

(P.S., all of this goes out the window when you're talking about an 
organization issuing certs to its members/employees/students/whatever. 
That's the intent of my effort, with the totally free email-only certs 
piggybacking.)

Bear

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

Re: using an on-disk session caching framework

[Bear Giles]

Edward Chan wrote:

The default behavior of server-side session caching is
to cache session in memory.  This is probably not
gonna work very well if there are a lot of connections
to the server

It says to open file named according to session id. 
However, session_id contains non-ascii chars, chars
that are illegal in a filename.  So how can I name my
file according to the session_id?

If you have enough sessions that you need to cache them on disk, you 
probably don't want to write them one-to-a-file either.  Don't be so 
literal about the open file comment.

Instead, open a single database instance (e.g., a Berkeley DB in hash 
  mode, since you don't care about ordering) and use the session ID as 
your key ID.  The non-ASCII characters aren't an issue since you specify 
a pointer and length, not a null-terminated string, as your key.

In practice, I believe apache's mod_ssl uses sdb instead of traditional 
db files for some reason, and you should definitely investigate why. 
But definitely go with a single, very efficient container object instead 
of using the filesystem as one.  Even if you're guaranteed to be running 
on a new FS that uses btrees for the directory info, it's still much 
faster to do a hash lookup than a btree search, O(1) vs O(lg N).

Bear

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

Re: using an on-disk session caching framework

[Bear Giles]

Geoff Thorpe wrote:
 The hash-database means the only way to

remove expired sessions is to iterate across the entire database!


Or you maintain an auxillary database that maps the expiry time to a 
list of session IDs.  This could be a btree (perhaps with a bucket of 
session IDs, to avoid dulicate keys) or a priority queue, or a number of 
other things.

Since this is a much smaller structure, it could be maintained in 
memory.  If you restart the system you'll have to rebuild the auxillary 
database, but it should only take O(N lg N) time.

I agree that you could also use directories.  My concern is just that 
I've seen applications crawl because of the time required to scan a 
directory when there's more than a few hundred entries in it.  If you 
use directories to keep the entry count down, you can minimize this problem.

Bear

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

Re: free Certificate Authority

[Bear Giles]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I've been working on a similar project.  My approach, with notes, is:

- - JSP front-end.  This isn't so much for the forms as for the results
when you search the database - the JSP kicks out XML, but can run it
through XLST for browsers and clients that don't natively support XML.

- - the datastore is PKI-enhanced PostgreSQL.  This user library allows
all certs, cert requests, etc., to be stored as first-class objects and
defines stored procedure functions that mirror the OpenSSL library.
The idea is that the datastore can enforce some CA rules, e.g., before
you can insert a new record the signer of the record must be known to
the database.  (This is a deferred constraint so you can add new root
certs.)  Or if you invalidate a cert, a trigger will invalidate all
certs signed by this cert after some date.

- - the CA would actually be split into a CA (cert signer only), RA
(accepts requests, uses J2EE to allow automation of many requests), and
a CertStore (http, ftp, ldap interface to searchable database).  These
would be separate applications, and could eventually run on different
hardware.

- - for the actual signing, I was thinking about using a java card!  It's
slow, but the card can be set to never reveal its private key and you
can generate the top few levels of your certs (true root, working root)
then toss them in an envelope and then lock them into a safe.

Unfortunately, my project is on hold until I finish moving to Portland.
I may be able to get back to it early next year, and there's some
interest in launching a Portland area colo co-op and this would be one
of the founding projects.

Do you have a cite for that Gutman paper?  I've worked out a database
design myself, but would certainly like to check it against his
suggestions.

Bear
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE9vpWdmr0uXf8FxOURAqxjAJsFXZwrSALzXAmb/P5bbnCosqVk8gCfT8Bf
3lNVU8gxYnlHBn/PK6dnEow=
=XPQe
-END PGP SIGNATURE-

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

Re: Ephemeral RSA Keys

[Bear Giles]

 For a discussion of ephemeral RSA vs. ephemeral DH: I don't know. When
 switching from SSH-1 to SSH-2, RSA session keys were replaced with DH
 ones, but that may have been for patent reasons. Maybe somebody else
 can spread mor light on this point.

There's a bit of a discussion in _SSL and TLS_.

As I understand the issues (I just skimmed the sections), with 
ephemeral DH you can generate a new key inexpensively.  Probably 
something as simple as generating a very large random number X
and computing g^x mod p (where g and p are specified in the
DH parameter file).  This means you can generate a new key for
every session, providing maximum security (short of regenerating
the DH *parameters* every time!)

In contrast, RSA keys have to be regenerated every time.  That's
expensive, so implementations will typically cache the key and 
reuse it for a while.  This puts all of those sessions into the 
same boat, securty-wise.

There's are also some efficiency considerations since the private
and public keys in RSA tend to be about the same size, while DH
keys (I think) tend to have much smaller private keys, I think it's
a fixed size of something like 80 or 128 bits.  (I know this is the
case with DSA, but I'm not 100% sure about DH.)  This smaller
private makes some operations more efficient without compromising
security.

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

Re: Serial Number

[Bear Giles]

 Yes, you are right, it could be difficult to garantee that the random
 serial number will be unique. 

As an aside, I'm not sure this is such a major hurdle.  The CA
should be able to look up certs by serial number anyway, and if 
it can do that efficiently (e.g., you have a Berkeley DB DB_HASH 
table mapping serial number to filename) then you can use the same 
mechanism to ensure that random SNs are unique.

 Also a digest from timestamp will be more appropriate.

Another common choice is MMDDXX where the prefix is the
current date, and the XX is some random component.  This
still gives you the nice property that SN1  SN2 implies that
the first cert was issued after than the second cert (unless
the SNs are close), while giving you a large random component.

 My question for you is how to write this SN's value when
 I sign the CSR?

  X509_set_serialNumber(x, s);

but only if you're doing it in C instead of the CLI level.  In fact,
getting the ability to set SNs to what I wanted is one reason why I
went with some local C programs instead of the standand CLI tools.

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

Re: secure mailinglists

[Bear Giles]

 Message senders encrypt the message with the public key of the
 mailinglist. The mailinglist server decrypts the message using the
 private key for the mailinglist and encrypts it again individually
 for every recipient. The problematic part is the signature, I guess.
 Would it be possible to keep the original signature?

Sure, but you would need to ensure every tool sees the signature
and encryption as separate stages.  IIRC the PKCS7(?) standard
correctly, you can nest them so that instead of a signed and 
encrypted message you would have an encrypted message which 
contains a signed message.

But this comes back to the point Vadim raised - you need to
determine what the tools can support and work around that 
limitation.
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: doubt regarding the RA certs

[Bear Giles]

 What is the use of RA certificates?
 What is the purpose of key usage extension values in CA or RA certificates?
 
Since nobody else has commented, I'll toss out my ignorance for all
to mock... :-)

If you have both a RA and CA then the RA usually handles the question 
of whether you should get a cert and what policies apply to it, while 
the CA handles publishing it to the world.

As a concrete example, the RA may be run by the HR department, and
it determines whether you're an employee or not, whether you're a
manager or not, etc., and it then hands it off to Verisign (CA) to 
manage.

Or it may be a schools registar (is this an undergrad student?  a
grad student?  a faculty member?), and it hands it off to a CA run
by the university IT group.

Anyway, in a case like this one way to handle the RA-CA traffic is
for the RA to sign certs that it approves, and then the CA re-signs
them with the published CA certs.  The RA needs to be able to sign
certs, but you really want everyone to use the certs published by the
CA, not the RA.  Hence the usage restrictions.

Hope this helps
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Getting OpenSSL with Apache

[Bear Giles]

 Cannot load /usr/local/apache_test/libexec/libssl.so into server

Have you verified that the usual symbolic links exist?

/usr/local/apache_test/libexec/libssl.so - libssl.so.0
/usr/local/apache_test/libexec/libssl.so.0 - libssl.so.0.9.6

and that the actual file is readable, non-empty, etc.?

 Where does the system search for libssl.so.0.9.6?

Whereever it's told to. :-)  Linux uses ld.so.conf; I don't recall
what Solaris uses for the same purpose.

But the error message suggests that it's looking in the right 
place, but some symbolic links are missing.
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Getting OpenSSL with Apache

[Bear Giles]

Following up on my earlier comments

  Cannot load /usr/local/apache_test/libexec/libssl.so into server

The fact that I missed this at first is proof that programmers 
shouldn't work when still running a fever.  Even a low grade one,
if it's following a 40C monster.

libexec is normally used by the shared libraries used by Apache
modules, not by system libraries.  mod_ssl is a weird beast, but
if you compiled it to use the system SSL library you should probably
make sure that openssl is set up in some system library.

The fastest way to do this may be to forget about Apache entirely
for now - get a simple program like:

  #include openssl/crypto.h

  int main()
  {
 (void) OPENSSL_malloc(1024);
 return 0;
  }

to compile and run.  That will assure you that the SSL library
(or at least the -lcrypto part of it) is properly installed.  Once
you know this, you'll know any remaining issues are mod_ssl or
Apache specific.
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: SQL DB instead of index.txt

[Bear Giles]

  I can think of multiple
  common storage formats: text files, DBM files, LDAP, RDBMS.
 
 why not use an existing database abstraction layer such as libdbi or ODBC?
 
Too abstract - queries are done with SQL statements.  That's not a
problem with a RDBMS backend, but requires a lot of extra code with
everything else.  Even if you identify a set of standard query strings
and use hardcoded strcmp(), maintenance is a nightmare.

All you really need is a simple api: store(), remove(), lookup(),
revoke() (or update()?), maybe a few more, and a dynamic library
loader.  And some configuration code that allows the user to specify
which dynamic library to load.  (Then again, in this case it may be
okay to just create a symlink from some standard name to the desired
dynamic library.)
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: SQL DB instead of index.txt

[Bear Giles]

(Slightly OT, but it is important to anyone looking at storing
these objects in a relational database.)

 with postgres 7.1 the 8k limit is gone anyway.

Yes and no.  What 7.1 added - and why I don't support older versions -
is TOAST support that tells the database server that it's okay to
move the user-defined type out of the main record if necessary.
By default new user-defined types remain in the main record and that's
still limited to 8k.

Since the well-defined types (both standard and user-defined) now
support this, it's fair for the casual user to say that the 8k limit
is gone.  But anyone working in the backend needs to deal with this
issue.
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: SQL DB instead of index.txt

[Bear Giles]

 A simple question, but not a least:
 instead of using the index.txt file as database of registered certificates,
 could it be possible to use a SQL database e.g. PostgreSQL as the
 engine version of openssl can with HSM e.g. nCipher

My PKIX extensions to PostgreSQL 7.1.x provide native support 
for certificates, CRLs and key (PKCS8) objects.  It also supports
PKCS7 encrypted objects.  

The external representation is always PEM (with accessor functions
to get most of the fields), the internal representation is ASN.1,
and the data is TOASTable so you aren't bound by the usual 8k 
limitations.  The library is mostly glue between the PostgreSQL
backend and the OpenSSL library.

The intention was provable consistency, not raw performance.  For
instance, in the cert repository mentioned below I recommend a
referential integrity check that requires the issuer of a cert
also be in the database.

The latest version also has a simple Jave JSP/servlet cert repository,
with certificate authority and registration authority on the way.
It supports all of the search criteria recommended by Gutman, and
besides the direct mode it can produce XML.  The goal is to use
XML and XSLT to produce results in whatever format you want.

On the C side, it should be easy to create a wrapper library that
uses ESQL/C (ecpg) to access the database.  Just use a host variable
and the BIO routines that use memory buffers.  With ESQL/C, it
would be easy to migrate to a different RDBMS if necessary.

Long term, it would be best to create an abstraction layer that
would allow any backend to be used.  I can think of multiple
common storage formats: text files, DBM files, LDAP, RDBMS.  But
that's definitely not a 0.9.7 task!

libpkixpq is available  at: http://www.dimensional.com/~bgiles/
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Announcement: libpkixpq 0.4 (pkix + strong crypto for db)

[Bear Giles]

I am pleased to announce the release of libpkixpq 0.4, a major release.

NEW FEATURES


 - documentation

 - support for PKCS7 asymmetric encrypted messages.
   (OpenPGP symmeric encryption support has been dropped, at
   least temporarily.)  The PKCS7 asymmetric encryption 
   includes support for recovery keys, but not for multiple
   recipients.

 - support for the OpenSSL TYPE_print functions as used 
   defined functions for the standard types,

 - a new text type, XML, which indicates X.509 certificates,
   X.509 CRLs (rsn), and public keys should be written or
   parsed as specified by the W3C XML Signature schema. 

   This means that the XML representation of a certificate
   can be intuitively obtained via a query such as:

 select cast(cert as xml) from certs where ...

   The corresponding input functions are not yet implemented.

 - the initial release of a JSP/JSP tags X.509 certificate
   repository, part of a CA tentatively named 'beastmark.'
   This repository can be searched in all manners covered by
   Gutman et al, and is designed to use XML natively (hence
   the prior item) and XSLT to convert results to the 
   appropriate format for the client - text/html,
   application/x509-certificate, application/x-x509-ca-cert,
   etc.

SOURCE CODE AVAILABILITY


Source code can be downloaded from http://www.dimensional.com/~bgiles/ ;
as always US export laws apply.

Documentation online at http://www.dimensional.com/~bgiles/pkixdoc/

Message cc'd to [EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: invalid Security Certificate file when attempting to load CA certto MSIE 6.0 (W2K)

[Bear Giles]

 This works with Netscape 6, but still no luck with MSIE.  Can anyone
 help?

 I then try to upload CAcert.pem to browser as mime-type
 application/x-x509-ca-cert.  

You should have specified problems with MSIE earlier.  I saw the
Netscape-ism and assumed you were having problems with Netscape, not
MSIE.

One of Microsoft's many weird fetishes is file extensions.
(see also the recent attacks where MSIE downloaded image/jpeg 
files bypassing the security manager, then cheerfully attempted 
to execute them since the image had a file extension of .exe)
(Another well-known fetish is the insistence on drive letters
long after computer networks became the norm in offices.)

Try changing the extension on your certificate to the .cer, which
I believe has the Bill Gates Seal of Approval for use as the file
extension for digital certificates.

If you still have problems, try changing the MIME type to
application/x509-certificate.
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Creating and Installing Client Certificates - ??

[Bear Giles]

 I would like to have a user open a webpage and supply DN info.  I would
 then like the CGI  client-side scripts to request a certificate from
 OpenSSL on the server (Linux) side, return it to the client and have it
 imported into the client's (MSIE/Win2K) store.  

As an aside, this is exactly what my JSP/java servlet CA beastmark
is intended to do.  It will:

 - store the certs in a PostgreSQL backend,

 - generate HTML forms with JSP, making it easy to modify content
   such as JavaScript and ActiveX controls used on the client side,

 - 'catch' the forms with Java servlets.  Servlets, database 
   triggers, or external applications can handle approvals (moving 
   from 'pending' to 'approved' or 'rejected') status,
 
 - publish the results via the standard CA search functions.

The database backend is why I've put some effort into defining
new PostgreSQL data types and functions.  To be really useful
you need to have good search capabilities, and a relational
database makes this easy.  (The other common approach, LDAP,
is also covered by using the relational database: make that
database the backend of the LDAP database.)

I had hoped to get the first set of servlets, which handle
cert queries, out by today but the sewer line backed up over
the weekend.  It will hopefully be out within the next few days.

This may not solve your immediate needs, but then again it may
already have a lot that you can use.
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Root cert questions

[Bear Giles]

 By definition, a root cert is one where the issuer is also the signer.
 How you determine issuer===signer can be problematic (insert various 
 Gutman data here :), but most software probably compares DN's.

I might not have been clear on this - the table is intended to be 
used as the cert store for certs issued by the CA, not a general
purpose cert store.  The CA has complete control over everything 
that goes into the table, and will include a bunch of companion java 
servlets that query the database.  (Think nsRevocationUrl and the
like, or similiar PKIX lookup functions.)  If the database has 
strong integrity checks, the servlets can be thin.

Anyway, my current test for a root cert has been whether

  X509_verify(cert, X509_get_pubkey(cert))

  (or x509_verify(x,x) in the PostgreSQL binding)

returns true.  I originally planned to compare keyids, but have 
decided to just cache the results of this test instead.  I've been
ignoring the subject and issuer DNs for now from the assumption
that an attacker could exploit any difference in how I recognize
root certs (self-signature or subject/issuer DN) to slip in some
bad certs.

But this is an exercise in futility unless the cert chains will
be acceptable to others, hence the questions.

 If your 
 libpkixpg functions generate the keyid if not present, then your schema 
 looks correct.

Nope, if the keyid is absent you get a null.  But this isn't an
issue since my signing code always adds the keyids.

 A more correct term, although not as impressive, is 
 probably self-signed cert.

Since the intention is to label the terminal certs in a cert chain
maintained by the CA, a root cert could be a CA cert signed by a 
third party.  That's the end of the chain as far as the database is
concerned.  You're unlikely to get such a cert from Verisign, but 
you might get a restricted one from a parent organization.

In this case, the test for root certs would become something like

  X509_verify(cert, X509_get_pubkey(parentcert))

where the 'parentcert' is the foreign signing key.
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: RSA keys auth.

[Bear Giles]

 Jeffrey Altman wrote:
 
  A passphrase consisting of human readable/typable text provides
  approximately 2 bits of entropy per character.  
 
 English text contains approx. 3.5 bits of entropy per character.

Password half password of password normal password English password
text password is password not password the password 'password', password 
or password similar password text password.

(I know, the, a, in, of, etc.  But these extremely common 
English words are also extremely short, and are often eliminated
from these entropy counts anyway as 'semantic glue.')
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Outlook mail encryption

[Bear Giles]

Can't answer your question, but...

 I need to create X509v3 Certificate for client authenication and email
 encryption and signing.
 I create PKCS10 request (taken from MSDN example)

Is this example online?  I'm working on this problem myself right
now (just got the request into the database and signed)

 strReq = Enroll.createPKCS10( strDN, 1.3.6.1.4.1.311.2.1.21)

The sample code I found (all in Russian :-( ) has a NID
1.3.6.1.5.5.7.3.2 there.  Don't know if it matters.

My request has attribute NIDs 1.3.6.1.4.1.331.13.2.2 and 
1.3.6.1.4.1.331.13.2.3.  Again, I have no idea what they mean - and 
OpenSSL can't even print the first attribute.

 Then import generated X509 as Personal certificate and as Other People
 certificate.(AcceptPKCS7,InstallPKCS7)

Could you send me sample code?  I know how to return certs for Netscape,
but not MSIE.

 Received Certificate works for authenication and signing
 but [not encryption].

What are the permissions on the cert you actually produced?  Is it
possible that you somehow stripped permissions?
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: m*n type of password protection...

[Bear Giles]

 There are devices out there where you can protect something 
 with n password, of which any m (m = n) are
 required to unlock the encrypted something.
 
 The second method involves some clever
 splitting of something and some kind of protection of each part.

My copy of Applied Cryptology is hiding, again, but I know
it discusses this.  You use the secret to define a set of 
linear equations over a finite field, and distribute only some
examples to each person.  As a trivial example, if the secret
you want to protect is 25, you might use

x = 2, y = 5, secret = 10 * x + y

3 x  + 7 y = 1 (modulo 10)
5 x  + 2 y = 0 (modulo 10)

(where the coefficients are picked at random, except you do
want to eliminate any duplicates).  You give Alice (3, 7, 1; 10) 
and Bob (5, 2, 0; 10).  Neither can solve the equation their 
information alone, but it's a trivial problem with both keys.

Of course, Alice could enumerate all possibilities that satisfy
her equation.  It's not too bad with this equation... but in 
practice your secrets won't be that small.  For instance, one
secret worth protecting is the 128-bit session key used to
encrypt a sensitive file.  If you have half the of the necessary
equations, you still need to explicitly try 2^64 possible keys!

As long as the equations are independent, you can use as many
samples as you wish.  This allows you to give some people more
authority, e.g., to allow two senior managers to get access,
but require at least 5 mid-level managers.

 My goal is to apply whatever I come up with on usual PEM-formatted RSA
 keys, and possibly to insert code in OpenSSL for this.

I would suggest that you keep the key in PKCS8 format, but
with a random encryption key that's protected in this manner.

The protected key is best held in a bag of some type (perhaps
one of the existing types?), with each entry containing a hash
of the public key (so you can figure out what it decrypts!) and
a sequence of ASN.1 integers for each coefficient and the 
result.

A variant of this can be used to make keys that can always be
retrieved by a suitable authority - they just get a bag with
enough samples to solve the equation.

Bear Giles
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Intermediate signing certs

[Bear Giles]

  This doesn't help you when presented a naked cert by a stranger[...]
 
 Any parseable certificate presented by a strager is good enough to
 use that public key to send email encrypted to *his* private key.
 At least if there's no chance for man-in-the-middle.
 
Not if the cert denies such use... and at most all it gives you is a 
secure channel back to the person who sent you a possibly fradulent
cert.  If you aren't willing to blindly trust their cert, why would
you blindly trust a cert chain and root cert (or pointer to same) they
send?

 Probably you are talking about verification that stranger is authorized
 by some big guy to pay..it's completely different issue.

Or authorized to use resources, access data, etc.  At an extreme, it
might only be used to log the identity of persons in open discussions.
That might sound excessive, but the spammers and slanderers may force
some forums to go to this extreme.  Anyone who posts as [EMAIL PROTECTED]
is exactly the type to create their own bogus certs.

 One could care about CA certificates related to his business, either
 well-known or private ones used to verify access to local resources.
 
Of course, but what about a case where you've never heard of them
before?  Your server asks for a cert, they hand over the only one
they have, and you're suddenly wondering how much weight to give it.
(See comments above.)

  On a related note, is there documentation on how to set up a well-
  behaved certs and PKCS12 bags?  I couldn't find anything the last
  time I checked, but maybe something has come out since then.
 
 Any problem with PKCS12 specifications published by RSA Labs?
 What is well-behaved ?

It's hard to describe well-behaved because I rarely use Windows
clients, and on Unix I tend to use the locally generated stuff 
with installers.  But I've noticed that instead of loading several
items separately, on PCs you often get everything in one package.

So the question isn't how to create these packages (I assume the 
library will hand that), but what to put into them.  And as my earlier
comment suggests, I'm not even sure if this is a PKCS7 or PKCS12 object -
I've been working with X.509 certs (and requests) and PKCS8 keys 
exclusively.

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

Re: Intermediate signing certs

[Bear Giles]

 Would this be a hassle if you have a root CA with a lot of intermediate
 signers?  That means that you have to store/locate all possible intermediate
 signers to evaluate a couple of end user certificates.

This is why PKCS12 (iirc) provides a mechanism to provide intermediate
certs with the final cert.  The CA should have a suitable chain for its
own certs, and it can return the extra certs with everything that it 
signs.

This doesn't help you when presented a naked cert by a stranger - you
still have to locate those intermediate certs - but at that point you 
have more problems than just finding the intermediate certs.  What does
it mean to have a full cert chain if the root is a self-signed cert by 
Bob's Bait Shop and Certificate Authority? 

You could decide to ignore any cert that's not from a major CA (which
would make the stockholders of Verisign very happy), but that misses
the point.  An individual cert by Verisign really says very little about
the person, a cert signed by a small college for its students for
internal use may be rock solid.

On a related note, is there documentation on how to set up a well-
behaved certs and PKCS12 bags?  I couldn't find anything the last 
time I checked, but maybe something has come out since then.

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