Re: How to securely encrypt identical files to identical ciphertext?

[Roberto Spadim]

* a point in my last email...
"... but underground world is nice and many times free =] ..."
the "nice" != "legal", check your country law before doing crypt and others
protection features

Re: How to securely encrypt identical files to identical ciphertext?

[Roberto Spadim]

hum, i will talk again with general cases, but it give nice ideas

the point about security is fisic access...
you have problem with fisic access to disk? for example, if you put your
data in a datacenter, you never know who is changing your hardware or what
happen to hardware disks... at least i don't see anyone putting webcams
outside the server and record everything that happen outside server...
in this case you should check that datacenter admin can copy your disk and
do what he/she want... (it have the fisic acces to it, and yes it CAN do
this, ok maybe it's illegal, but what ever... it can do it)

when someone have a file for example 10MB, encrypted it will try data
dictionary, and brute force attacks, probably it will load the file to
memory and send to many computers to decode this file... 10MB in a memory
is something very small run memtest86+ in your computer... you will see
>2GB/s of speed on memory access... with many computers 10MB could be near
to 1byte (talking about read speed and decode speed)... well just to
explain the relative size when using many computers not true values...

well you can't do nothing, with time he/she will get the file... the only
solution is legal... but he/she can send your files over internet and
anyone could get it...

but... you have some alternatives... make attacker job harder
one nice feature is a "pseudo cryptografy" called steganography, instead of
a cryptography where attackers know that a file is crypted, you 'give' a
file that any users could see (for example a image or a music or a video)
and add your information in that file like a water mark... i didn't
searched about filesystems tools (for example using LUFS) to steganography
files online... but it's a nice feature for high security systems... the
attacker will think that it have the file, and it have the file, but it
will think that the information is a image, while the information is the
watermarks in the image... it's very very nice for security since the
inteligence of attacker is get a well know file format, and not a specific
information, the specific information is only searched if the attacker
really know that you have important information and the kind of information
(for example instead of finding a file, it will try to find text, and know
that is possible to have a steganography software running in your
filesystem), but again... with time attacker can get the information...

well getting back to plain salt... yes it's not as secure as a non blank
salt, i will talk about my idea of statistic in this case, not as a
probability model... maybe the attacker could use your salt at first
time... maybe not... the salt must be something that you probably will not
use and attacker will not think (or calculate) it too soon, again with time
it can calculate... but you should give your best to make it too hard to
calculate or think that it could be used, the blank salt is something that
every body will try at first time (at least me... i will try blank, 1234,
12345,1234567, ,  ... and others number combinations)

well when someone stole your data you can't do nothing, the best method is
physical protection, burn your disk for example like 007 james bond :)


again, i didn't know if i solved your question, just some ideas about
increase security...

if you really want know if your system is secure, the most interesting
thing you could do is know some underground group and tell they to unlock
your information, there's some companies that do this job too, but
underground world is nice and many times free =]

good luck :)

Re: How to securely encrypt identical files to identical ciphertext?

[Unga]

>
> From: Roberto Spadim 
>To: openssl-users@openssl.org 
>Sent: Friday, August 16, 2013 6:01 PM
>Subject: Re: How to securely encrypt identical files to identical ciphertext?
> 
>
>
>hi, i don't know if i will answer your question, but i will give some tips 
>about security...
>
>the point about decrypt is crypt lists, reverse engeneer and many others 
>solutions to decrypt informations
>i didn't remember the name, maybe rainbow list or something like it is a 
>normal feature used with hash functions
>a salt is very interesting since the list without salt is normally 'weak', 
>because anyone could create a list with a 
>
>
>for(i=0 to infinity)
>  crypted value (i) = crypt function ( i )
>and yes, many guys create this lists... it's nice, and it's a problem... maybe 
>you lost your password some day and found it in the list and ! now you have 
>your password back !
>
>
>about file decrypt, the "attacker" will try to decrypt a small part of file or 
>the full file, normally when i try to decrypt i know +- what file have (a know 
>file structure) in this case if the file is a image for example, or a zip 
>file, i will try to run a program to decrypt and only check if the magic 
>numbers of that know file structure is found, it's a way to hack a crypt, it 
>take many time (maybe never happen), but it's a easy to understand strategy... 
>there's more features about crypt/decrypt but i will give a superficial idea 
>only...
>
>
>in real world, a salt is important, some users use a MD5('salt' + MD5(password 
>+ 'salt2')) to ensure that the password isn't listed in a list or another 
>hash/crypt function... 
>well in my option (not statistic, but real world use cases) it's just a 
>placebo, the point here is... 
>if someone want your information, restrict the time he can try to read/access 
>your information... example... 
>a login system, should allow a 5 wrong logins, after this block by 5 minutes, 
>after more 5 wrong logins block for more 10 minutes... it's like iphone screen 
>lock, the attacker can have a very big high optimized cluster to extra world 
>solutions, but it only have 5 tryes to know the password / 5 minutes... well 
>sorry attacker i  could do the same job with my cellphone and maybe know the 
>right password ... that's not the case if attacker know more informations 
>about user password (her name, wife name, child name, birthday, first car, pet 
>names, etc...)
>
>
>again, the problem is: don't allow a intensive access to your information, if 
>this occur check if the user have permissions to do this, if not block it with 
>a pre fixed time and contact user... the user should ask about permission to 
>admin, and admin could add more permission to user that's the 'right way' 
>to add security to any system
>
>
>i don't know if this help you, but these are some tips about security and i 
>didn't checked if i answered your question :P sorry
>maybe i talked something wrong, it just a idea i didn't checked the normalized 
>ideas (there's some information at FBI docs about forense it's nice to read...)
>
>
>bye
>

Hi Roberto

Thank you for the reply.

My encrypted file is with you. It is encrypted without a salt. I'm scared you 
may use a sophisticated system to decrypt it and read the sensitive info. I use 
a per file not guessable 150 character password. This password is not repeated, 
only reuse on identical plaintext files only.


I want to understand is it any easy for you to decrypt it than a salted 
encrypted file?


Best regards
Unga

__
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 wrote:

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

Re: Encumbered EC crypto algorithms in openssl?

[Nico Williams]

If only we could agree to use DJB's Curve25519...
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: How to securely encrypt identical files to identical ciphertext?

[shathawa]

Besides using the same cipher (session) key, you also need to use the same
initialization vector.  Note: in practice, the initialization is a random
number that should not be reused.
- Steve
> Hi all
>
> I have a requirement to encrypt files, in such a way identical files
> should generate identical ciphertexts.
>
> I plan to use aes-256-cbc cipher with 128-byte long non-guessable password
> per input file. Identical input files will be provided with identical
> passwords.
>
> 1. Is it no salt the way forward for me?
>
> 2. How many rounds are recommended for EVP_BytesToKey() in my case?
>
> Many thanks in advance.
>
> Best regards
> Unga
>
> __
> 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

Encumbered EC crypto algorithms in openssl?

[Scott Doty]

Hello,

As you may or may not know, Red Hat has vetoed use of ECC in openssl in
their stock Fedora.  The bug regarding this is here:

   https://bugzilla.redhat.com/show_bug.cgi?id=319901


In a nutshell:  Red Hat is so afraid of patent trolls, they don't want
to enable ECC -- or even discuss the IP issues publically.  (And who can
blame them?  Legislative relief is definitely needed here -- so far, it
hasn't been enough.  But I digress...)

I see some references to standards in the sources for crypto/ec*, such
as ANSI X9.62 and IEEE 1363.  However, I'm not sure that that list is
inclusive -- and I certainly wouldn't be able to recognize whose
algorithm was being used by inspecting C code.  So I'm hoping for some
help with this, to allay Red Hat's fears of patent trolls.

Toward this goal, there is an informational RFC 6090 that outlines how
to implement ECC without patent encumbrance.  I'm wondering if we can
safely say that openssl's ECC is implemented in a way compatible with
RFC 6090 -- or at least, in a way that enabling it on Red Hat software
wouldn't open them up to a patent troll flawsuit?

   http://www.rfc-editor.org/rfc/rfc6090.txt

I checked the FAQ, and it does reference the README regarding patents. 
However, it doesn't specifically mention ECC, and that would seem to be
the sticking point with Red Hat.

With more and more software systems requiring ECC to operate, "I See A
Great Need" in getting this resolved.  Thank you for any information you
can provide.  Also, if this belongs on the dev list, my apologies for
coming here first.

-- 
 -Scott Doty
 Co-founder, Co-owner, CTO: Sonic.net, Inc.
 

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

Re: OSX Open SSL Usage question

[Dave Thompson]

>From: owner-openssl-us...@openssl.org On Behalf Of Ztatik Light
>Sent: Friday, 16 August, 2013 03:31

>From stackoverflow: 

>"These hash values will comes from the Subject DN of each 
>CA certificate (since the aim is to look for a CA certificate 
>with the subject matching the issuer of the certificate to verify). 
>You can either usec_rehash as documented, or get the Subject DN's 
>hash using openssl x509 -subject_hash -noout -in cacert.pem 
>and rename the file/link accordingly."

That most likely explains the "unable to get local issuer cert"
because 1.0.0 and later changed the subject hashing from 0.9.8,
so either the existing (0.9.8) certs dir needs to be rehashed, 
or you need to create a separate -CApath using 1.0.0 hash,
or just put the CA cert(s) you want in a -CAfile instead.

But it doesn't explain cipher NONE, which should only occur if 
the handshake fails, and it's pretty odd for that to occur 
after (receiving and) validating the server cert.

>On Thu, Aug 15, 2013 at 12:01 PM, Andrew H 
> wrote:

>   I have two version of OpenSSL on my OSX file system, 
>the default 0.9.8r and 1.0.1e. 
>   For the later I'm having trouble getting the syntax 
>of the command correct, I think.

>   When I used this (in 1.0.1e's directory, /opt/localbin):
>   ./openssl s_client -connect foo.foo.foo.foo:443 ( replace the foo's
).
>   I get responses that included the Cipher is NONE and 
>'unable to get local issuer certificate' messages.

>   Without the ./, using the default openssl, this works fine, 
>the cipher is populated and no local issuer messages.

>   I tried variations of the CApath argument with no success:
>   -CApath /System/Library/OpenSSL/certs/ 
>   That's the system path from 'openssl version -d'
>   I messed around with similar values in the verify argument.  

You can't use "similar" values, -verify takes a number (indicating 
depth) and isn't really implemented anyway (the callback ignores 
it entirely unless there's already another verification error, 
and then it sets a variable that isn't used!)

>   There's obviously a fundamental misunderstanding on my part 
>regarding the proper usage of these arguments.

These arguments for s_client haven't changed, although some 
other options were added. 1.0.1 newly implements TLSv1.1 and 
1.2 and defaults to the highest available. 1.2 in particular 
has been known to cause problems with some (lame) servers. If 
you still can't connect after fixing CApath as above, try adding 
-no_tls1_2 or more restrictively -tls1 or -ssl3 . If that makes 
the difference and you want to understand what the exact problem 
is, show us *all* the output for a 1.2 attempt. 


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

Re: EVP_DigestSign*() and EVP_DigestVerify*() - help needed

[Ken Goldman]

The usual cause of a padding error is that the private key used to sign 
does not correspond to the public key used to verify.


That is, unless you're a newbie to crypto.  In that case the error is 
that you're passing the length of an encrypted blob using strlen().


The way I typically debug is to do a raw public key operation and trace 
the result.


On 8/16/2013 4:09 PM, Thomas J Pinkl wrote:

I'm using OpenSSL 1.0.1e and attempting to use the EVP_DigestSign*() and
EVP_DigestVerify*() functions from within my C code.  I am able to
produce a digital signature using EVP_DigestSignInit(),
EVP_DigestSignUpdate(), and EVP_DigestSignFinal().  However, when I use
the corresponding EVP_DigestVerify*() functions, EVP_DigestVerifyFinal()
fails with:

139731000714920:error:0407006A:rsa routines:
RSA_padding_check_PKCS1_type_1:block type is not 01:rsa_pk1.c:100:
139731000714920:error:04067072:rsa routines:
RSA_EAY_PUBLIC_DECRYPT:padding check failed:rsa_eay.c:721:

I've tried the EVP_Digest{Sign,Verify}Init() functions both with and
without a EVP_PKEY_CTX pointer.  When the EVP_PKEY_CTX pointer was
provided, a variety of padding options have been tried, including
RSA_PKCS1_PADDING.

If anyone can provide some guidance on this, I would appreciate it.




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

EVP_DigestSign*() and EVP_DigestVerify*() - help needed

[Thomas J Pinkl]

I'm using OpenSSL 1.0.1e and attempting to use the EVP_DigestSign*() and 
EVP_DigestVerify*() functions from within my C code.  I am able to 
produce a digital signature using EVP_DigestSignInit(), 
EVP_DigestSignUpdate(), and EVP_DigestSignFinal().  However, when I use 
the corresponding EVP_DigestVerify*() functions, EVP_DigestVerifyFinal() 
fails with:


139731000714920:error:0407006A:rsa routines: 
RSA_padding_check_PKCS1_type_1:block type is not 01:rsa_pk1.c:100:
139731000714920:error:04067072:rsa routines: 
RSA_EAY_PUBLIC_DECRYPT:padding check failed:rsa_eay.c:721:


I've tried the EVP_Digest{Sign,Verify}Init() functions both with and 
without a EVP_PKEY_CTX pointer.  When the EVP_PKEY_CTX pointer was 
provided, a variety of padding options have been tried, including 
RSA_PKCS1_PADDING.


If anyone can provide some guidance on this, I would appreciate it.

--
Thomas J. Pinkl

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

Re: How to securely encrypt identical files to identical ciphertext?

[Roberto Spadim]

one idea...
use a salt with a MD5(file contents) + pseudo random salt based on others
informations
this give a nice salt...

example...

with different salts:
file1 contents = file 2 contents
salt of 1 = MD5(MD5(file1 contents) + file1 name)
salt of 2 = MD5(MD5(file1 contents) + file2 name)

or if you want same salts
salt of 1 = MD5(MD5(file1 contents) + "fixed text")
salt of 2 = MD5(MD5(file2 contents) + "fixed text")

since file1 contents = file 2 contents the salt will be the same, and since
information and salt is the same the crypt function will return same values
(if it's not based in another information, ie time of crypt function)

Re: Displaying cert with ecdsa

[Robert Moskowitz]

On 08/14/2013 05:37 PM, Dave Thompson wrote:

From: owner-openssl-us...@openssl.org On Behalf Of Robert Moskowitz
Sent: Wednesday, 14 August, 2013 15:49
I have a CA cert in pem format that uses ecdsa.  I have tried
to display the contents with:

openssl x509 -in x509-ca.pem -text -nameopt multiline -noout

I get errors:

  Subject Public Key Info:
  Public Key Algorithm: id-ecPublicKey
  Unable to load Public Key
140661212006240:error:0609E09C:digital envelope
routines:PKEY_SET_TYPE:unsupported algorithm:p_lib.c:239:
140661212006240:error:0B07706F:x509 certificate
routines:X509_PUBKEY_get:unsupported algorithm:x_pubkey.c:155:

Is there an option I need to add?  Is there something special
with this cert's Public Key Algorithm?

I'm pretty sure not. OpenSSL versions before 1.0.0 needed a
cipherstring option to use ECC suites *in SSL/TLS protocol*,
but local operations have worked as long as I remember.

What version of OpenSSL are you running, and how was it built?
In particular was it from official source, or patched?


I am running Fedora 16, standard biuld stuff. Yes, I know it is time to 
upgrade...


Openssl seems to be 1.0.0.k-1 per the yum log (I tried a -v option, but 
that does not seem to be supporte, nor --version).


The fellow that sent me the .pem has 1.0.1c-10 and was able to send me 
the dump of the cert and the PK algorithm is id-ecPublicKey and the ASN1 
OID: prime256v1


So now at least I can move forward reviewing what they are doing with 
this cert, but it would be nice to be able to display it myself.




A couple of remote possibilities: do you have your openssl.cnf
set (editted) to load an "engine", which doesn't support ECC?
I didn't think this level of parsing goes to an engine, but
I could be wrong. Do you have a FIPS-capable build and a
setting to force FIPS mode? FIPS should allow ECC (it is
NIST "Approved"), but something might be broken.

Can you try the same file with a different OpenSSL version
or build -- often easiest by using a different system?


__
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: weird bug

[Ken Goldman]

On 8/16/2013 1:51 PM, Ztatik Light wrote:

found yet another weird peculiarity...

In my full application, i need the following lines after both
encrypt_file() and decrypt_read(), otherwise i get garbage data:

char err[1024];
ERR_error_string( ERR_get_error(), err );
printf( "%s\n", err );

And err is 0... but without those three lines then i get garbage data
decrypted

And if i use a format string like ">%s\n" i also get garbage again. HAS
to be "%s\n". I have no idea wtf is up with all these bugs but i'm
surprised openssl is this glitchy


I would hesitate to blame openssl, used by 1000's of people for many 
years, while being so confident that your new code is bug free.


In particular, you observed that allocating an extra 1024 bytes on your 
stack fixes the problem.  You also observed that the bug is sensitive to 
the number of bytes in an array.


I conclude that you're overwriting some variable on your stack.


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

Re: How to securely encrypt identical files to identical ciphertext?

[Unga]

- Original Message -

> From: Matt Caswell 
> To: openssl-users@openssl.org
> Cc: 
> Sent: Friday, August 16, 2013 4:10 PM
> Subject: Re: How to securely encrypt identical files to identical ciphertext?
> 
> On 16 August 2013 16:46, Swair Mehta  wrote:
>>  On 16-Aug-2013, at 7:49 AM, Unga  wrote:
>> 
>>>  Hi all
>>> 
>>>  I have a requirement to encrypt files, in such a way identical files 
> should generate identical ciphertexts.
>>> 
>>>  I plan to use aes-256-cbc cipher with 128-byte long non-guessable 
> password per input file. Identical input files will be provided with 
> identical 
> passwords.
>>> 
>>>  1. Is it no salt the way forward for me?
>>> 
>>> 
>>  Identical salts(ivs) should work. No salt works as well.
>> 
> 
> This would have the effect that two files which were identical at the
> beginning for the first x number of blocks (but different afterwards)
> would encrypt to the same first x number of blocks.
> 
> Matt
> 

Hi 

Thanks for the reply.

I have mentioned I use the same password only if files are identical.

I get vastly different two AES encrypted cipher texts for two very large files 
with only one character different.

So is my approach any less secure?

Unga

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

Re: How to securely encrypt identical files to identical ciphertext?

[Roberto Spadim]

hi, i don't know if i will answer your question, but i will give some tips
about security...

the point about decrypt is crypt lists, reverse engeneer and many others
solutions to decrypt informations
i didn't remember the name, maybe rainbow list or something like it is a
normal feature used with hash functions
a salt is very interesting since the list without salt is normally 'weak',
because anyone could create a list with a

for(i=0 to infinity)
  crypted value (i) = crypt function ( i )

and yes, many guys create this lists... it's nice, and it's a problem...
maybe you lost your password some day and found it in the list and ! now
you have your password back !

about file decrypt, the "attacker" will try to decrypt a small part of file
or the full file, normally when i try to decrypt i know +- what file have
(a know file structure) in this case if the file is a image for example, or
a zip file, i will try to run a program to decrypt and only check if the
magic numbers of that know file structure is found, it's a way to hack a
crypt, it take many time (maybe never happen), but it's a easy to
understand strategy... there's more features about crypt/decrypt but i will
give a superficial idea only...

in real world, a salt is important, some users use a MD5('salt' +
MD5(password + 'salt2')) to ensure that the password isn't listed in a list
or another hash/crypt function...
well in my option (not statistic, but real world use cases) it's just a
placebo, the point here is...
if someone want your information, restrict the time he can try to
read/access your information... example...
a login system, should allow a 5 wrong logins, after this block by 5
minutes, after more 5 wrong logins block for more 10 minutes... it's like
iphone screen lock, the attacker can have a very big high optimized cluster
to extra world solutions, but it only have 5 tryes to know the password / 5
minutes... well sorry attacker i  could do the same job with my cellphone
and maybe know the right password ... that's not the case if attacker know
more informations about user password (her name, wife name, child name,
birthday, first car, pet names, etc...)

again, the problem is: don't allow a intensive access to your information,
if this occur check if the user have permissions to do this, if not block
it with a pre fixed time and contact user... the user should ask about
permission to admin, and admin could add more permission to user that's
the 'right way' to add security to any system

i don't know if this help you, but these are some tips about security and i
didn't checked if i answered your question :P sorry
maybe i talked something wrong, it just a idea i didn't checked the
normalized ideas (there's some information at FBI docs about forense it's
nice to read...)

bye

RE: weird bug

[Salz, Rich]

Ø  I have no idea wtf is up with all these bugs but i'm surprised openssl is 
this glitchy

It is not.  The problem is almost definitely in your code.  It is also hard to 
help when the code you post isn't the code you're trying to debug.

Get and run valgrind and see what it says.  Compile with many -W flags.

/r$

--
Principal Security Engineer
Akamai Technology
Cambridge, MA

Re: weird bug

[Ztatik Light]

found yet another weird peculiarity...

In my full application, i need the following lines after both
encrypt_file() and decrypt_read(), otherwise i get garbage data:

char err[1024];
ERR_error_string( ERR_get_error(), err );
printf( "%s\n", err );

And err is 0... but without those three lines then i get garbage data
decrypted

And if i use a format string like ">%s\n" i also get garbage again. HAS to
be "%s\n". I have no idea wtf is up with all these bugs but i'm surprised
openssl is this glitchy


On Fri, Aug 16, 2013 at 11:16 AM, Salz, Rich  wrote:

> **Ø  **Seriously - if i just use des instead of des_ede3 in works. that
> simple. has got to be a bug
>
> ** **
>
> Run your code through something like valgrind
>
> ** **
>
> ** **
>
> --  
>
> Principal Security Engineer
>
> Akamai Technology
>
> Cambridge, MA
>

Re: How to securely encrypt identical files to identical ciphertext?

[Unga]

- Original Message -

> From: Swair Mehta 
> To: "openssl-users@openssl.org" 
> Cc: 
> Sent: Friday, August 16, 2013 3:46 PM
> Subject: Re: How to securely encrypt identical files to identical ciphertext?
> 
> On 16-Aug-2013, at 7:49 AM, Unga  wrote:
> 
>>  Hi all
>> 
>>  I have a requirement to encrypt files, in such a way identical files should 
> generate identical ciphertexts.
>> 
>>  I plan to use aes-256-cbc cipher with 128-byte long non-guessable password 
> per input file. Identical input files will be provided with identical 
> passwords.
>> 
>>  1. Is it no salt the way forward for me?
>> 
>> 
> Identical salts(ivs) should work. No salt works as well.
> 
> Not sure what the requirement is here. The very point of crypto is
> that u dont leak any info at any cost.
>

Hi

Thanks for the reply.

The only info leak or known may be that my encryption generates identical 
cipher texts for identical files, and the pain text file is not known and the 
password also not known. I'm using very long non-guessable per file unique 
passwords. If by some luck find a password, it can only be used to decrypt one 
file, not any other file. So my question is, if I use no salt, does it become 
any less secure?

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

RE: How to securely encrypt identical files to identical ciphertext?

[Salz, Rich]

>>> I have a requirement to encrypt files, in such a way identical files should 
>>> generate identical ciphertexts.

>> Identical salts(ivs) should work. No salt works as well.

> This would have the effect that two files which were identical at the 
> beginning for the first x number of blocks
> (but different afterwards) would encrypt to the same first x number of blocks.

Derive the IV from a digest of the file.  Or encrypt the digest as the first 
"block"

/r$
 
--  
Principal Security Engineer
Akamai Technology
Cambridge, MA
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: DLL hell

[Nico Williams]

On Fri, Aug 16, 2013 at 02:44:23PM +, Viktor Dukhovni wrote:
> On Fri, Aug 16, 2013 at 07:17:22AM -0700, Thomas J. Hruska wrote:
> > I think a lot of the init logic heralds from the original SSLeay
> > days. There seems to be intent that initialization is supposed to
> > happen in main() in the application and libraries shouldn't be
> > calling initialization routines in OpenSSL.
> 
> This is a big problem, when main() has no knowledge of OpenSSL,
> rather OpenSSL is used indirectly via an intermediate library, that
> may even be dynamically loaded (e.g. Java dynamically loading
> GSSAPI, with Heimdal's GSS library using OpenSSL).

Right!

> Now it is certainly not appropriate for other libraries to call
> OpenSSL one-time initialization functions.  The result is a mess.

Exactly.

> Therefore, it is probably time to consider moving the OpenSSL
> library initialization code into OpenSSL itself, with the set of
> ciphers and digests to initialize by default as well as the thread
> locking mechanism chosen at compile time.

But would patches for this be welcomed?

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

Re: DLL hell

[Nico Williams]

On Thu, Aug 15, 2013 at 11:51:05PM -0700, Patrick Pelletier wrote:
> >Oh.  Is there any reason not to blow that away, or at least build-time
> >select which to use?
> 
> I'm in agreement with you; I just don't think you're going to get
> the OpenSSL folks on board.  They'll probably say something like "we
> want to be totally agnostic to threading library" without
> acknowledging that pthreads and Windows threads cover the vast
> majority of modern mainstream operating systems.

Ah...  I need OpenSSL developers to consider this.  Would that mean
re-posting to the openssl-dev list?

> >Great.  I was hoping that the response wouldn't be something like "no
> >way, we need these callback setting functions for XYZ reasons" or,
> >worse, "no way".
> 
> Unfortunately, I think the response will be that.  (The OpenSSL
> folks just haven't weighed in on this thread yet.)  That's why I was

I'm ever an optimist and I fail to see any reason to not make
initialization automatic and safe on all major platforms, keeping the
old callback setters as no-ops and as fallbacks in cases where
build-time configuration specifically requires that those setters not be
no-ops.

The alternative has to be "don't *EVER* use OpenSSL from a library", or
"always link with and initialize OpenSSL in every program that might -no
matter how indirectly- use an OpenSSL-using library", and *clearly* that
can't be what the OpenSSL devs want, or if it is, then it's clearly way
too late.

> floating the idea of writing an unofficial companion library that
> would smooth over these rough spots and provide a "batteries
> included" approach to people who want it, without having to convince
> the OpenSSL project to change the core library, which I think would
> be an uphill battle at best.

That can't really work unless *every* OpenSSL-using library used it, or
unless we specifically go for using symbol interposition (which means
dynamic linking, FYI, so it'd not work for statically-linked builds).

I'd like to get authoritative answers to my questions before considering
alternatives.

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

Re: How to securely encrypt identical files to identical ciphertext?

[Matt Caswell]

On 16 August 2013 16:46, Swair Mehta  wrote:
> On 16-Aug-2013, at 7:49 AM, Unga  wrote:
>
>> Hi all
>>
>> I have a requirement to encrypt files, in such a way identical files should 
>> generate identical ciphertexts.
>>
>> I plan to use aes-256-cbc cipher with 128-byte long non-guessable password 
>> per input file. Identical input files will be provided with identical 
>> passwords.
>>
>> 1. Is it no salt the way forward for me?
>>
>>
> Identical salts(ivs) should work. No salt works as well.
>

This would have the effect that two files which were identical at the
beginning for the first x number of blocks (but different afterwards)
would encrypt to the same first x number of blocks.

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

RE: weird bug

[Salz, Rich]

Ø  Seriously - if i just use des instead of des_ede3 in works. that simple. has 
got to be a bug

Run your code through something like valgrind


--
Principal Security Engineer
Akamai Technology
Cambridge, MA

Re: weird bug

[Ztatik Light]

yes, i fixed that.. it's not causing the problem..

Seriously - if i just use des instead of des_ede3 in works. that simple.
has got to be a bug


On Fri, Aug 16, 2013 at 10:49 AM, Salz, Rich  wrote:

> **Ø  **Some serious bug?
>
> ** **
>
> Yes, but in your code:
>
> **Ø  **char new_filename[strlen( filename + 5 )];
>
> ** **
>
> char new_filename[strlen( filename) + 5];
>
> ** **
>
> --  
>
> Principal Security Engineer
>
> Akamai Technology
>
> Cambridge, MA
>

Re: How to securely encrypt identical files to identical ciphertext?

[Swair Mehta]

On 16-Aug-2013, at 7:49 AM, Unga  wrote:

> Hi all
>
> I have a requirement to encrypt files, in such a way identical files should 
> generate identical ciphertexts.
>
> I plan to use aes-256-cbc cipher with 128-byte long non-guessable password 
> per input file. Identical input files will be provided with identical 
> passwords.
>
> 1. Is it no salt the way forward for me?
>
>
Identical salts(ivs) should work. No salt works as well.

Not sure what the requirement is here. The very point of crypto is
that u dont leak any info at any cost.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

RE: weird bug

[Salz, Rich]

Ø  Some serious bug?

Yes, but in your code:

Ø  char new_filename[strlen( filename + 5 )];

char new_filename[strlen( filename) + 5];

--
Principal Security Engineer
Akamai Technology
Cambridge, MA

Re: weird bug

[Ztatik Light]

If I simply replace "EVP_des_ede3_cbc" with "EVP_des_cbc" ... then it works
okay

Some serious bug?


On Fri, Aug 16, 2013 at 10:17 AM, Ztatik Light wrote:

> same result - did you actually try it?
>
> BIO_read is producing this error:
>
> "error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt"
>
>
> On Fri, Aug 16, 2013 at 3:28 AM, Ben Laurie  wrote:
>
>> Try
>>
>> write_data( file_, data, strlen(data) + 1, "mykey");
>>
>>
>>
>> On 16 August 2013 03:34, Ztatik Light  wrote:
>>
>>> ps, yes, line 29 is a mistake and should read: char new_filename[strlen(
>>> filename ) + 5];
>>>
>>> But even with that fix i get the same results
>>>
>>>
>>> On Fri, Aug 16, 2013 at 2:27 AM, Ztatik Light wrote:
>>>
 maybe not - still confused


 On Fri, Aug 16, 2013 at 2:21 AM, Ztatik Light 
 wrote:

> strange i think it has something to do with me using "rb" and "wb"
> instead of "r" and "w"...
>
>
> On Fri, Aug 16, 2013 at 2:14 AM, Ztatik Light 
> wrote:
>
>> So, I'm having a really weird issue... i'm trying simple file
>> encryption/decryption with BIO_*, but if the encrypted file is in a
>> subdirectory.. i get garbage data,
>>
>> I'll post the code i'm using, with a brief elaboration on how i'm
>> using it and what behaviour i'm getting:
>>
>> ///
>>
>> /*
>>>
>>>   Example of ssl read and write to a file
>>>
>>>
   gcc ssl_write_read.c -lssl
>>>
>>>   ./a.out
>>>
>>>

 */
>>>
>>>


 #include 
>>>
>>> #include 
>>>
>>> #include 
>>>
>>> #include 
>>>
>>> #include 
>>>
>>>
 int read_whole_file( char* filename, char** data ){
>>>
>>>  FILE* file = fopen( filename, "rb" );
>>>
>>>  fseek( file, 0, SEEK_END );
>>>
>>>  long fileSize = ftell( file );
>>>
>>>  rewind( file );
>>>
>>>  *data = malloc( fileSize );
>>>
>>>  fread( *data, fileSize, 1, file );
>>>
>>>  fclose( file );
>>>
>>>  return fileSize;
>>>
>>> }
>>>
>>> void encrypt_file( char* filename ){
>>>
>>> char new_filename[strlen( filename + 4 )];
>>>
>>>  strcpy( new_filename, filename );
>>>
>>>  strcat( new_filename, ".enc" );
>>>
>>>  char* data;
>>>
>>>  int fileSize = read_whole_file( filename, &data );
>>>
>>>  write_data( new_filename, data, fileSize, (unsigned char*)"mykey"
 );
>>>
>>>  free( data );
>>>
>>> }
>>>
>>>
 int write_data(const char *filename, char *out, int len, unsigned
 char *key)
>>>
>>> {
>>>
>>>   int total, written;
>>>
>>>   BIO *cipher, *buffer, *file;
>>>
>>>
>>>
>>>   /* Create a buffered file BIO for writing */
>>>
>>>   file = BIO_new_file(filename, "wb");
>>>
>>>   if (!file)
>>>
>>> return 0;
>>>
>>>
>>>
>>>   /* Create a buffering filter BIO to buffer writes to the file */
>>>
>>>   buffer = BIO_new(BIO_f_buffer(  ));
>>>
>>>
>>>
>>>   /* Create a base64 encoding filter BIO */
>>>
>>> //  b64 = BIO_new(BIO_f_base64(  ));
>>>
>>>
>>>
>>>   /* Create the cipher filter BIO and set the key.  The last
 parameter of
>>>
>>>  BIO_set_cipher is 1 for encryption and 0 for decryption */
>>>
>>>   cipher = BIO_new(BIO_f_cipher(  ));
>>>
>>>   BIO_set_cipher(cipher, EVP_des_ede3_cbc(  ), key, NULL, 1);
>>>
>>>
>>>
>>>   /* Assemble the BIO chain to be in the order
 cipher-b64-buffer-file */
>>>
>>> //  BIO_push(cipher, b64);
>>>
>>> //  BIO_push(b64, buffer);
>>>
>>> BIO_push(cipher,buffer);
>>>
>>>   BIO_push(buffer, file);
>>>
>>>
   /* This loop writes the data to the file.  It checks for errors
 as if the
>>>
>>>  underlying file were non-blocking */
>>>
>>>   for (total = 0;  total < len;  total += written)
>>>
>>> {
>>>
>>>   if ((written = BIO_write(cipher, out + total, len - total)) <=
 0)
>>>
>>> {
>>>
>>>   if (BIO_should_retry(cipher))
>>>
>>> {
>>>
>>>   written = 0;
>>>
>>>   continue;
>>>
>>> }
>>>
>>>   break;
>>>
>>> }
>>>
>>> }
>>>
>>>
>>>
>>>   /* Ensure all of our data is pushed all the way to the file */
>>>
>>>   BIO_flush(cipher);
>>>
>>>
>>>
>>>   BIO_free_all(cipher);
>>>
>>> }
>>>
>>>
 BIO* decrypt_open( const char *filename, unsigned char *key ){
>>>
>>>   int total, written;
>>>
>>>   BIO *cipher, *buffer, *file;
>>>
>>>   //char *b = malloc(len);
>>>
>>>
>>>

Re: weird bug

[Ztatik Light]

same result - did you actually try it?

BIO_read is producing this error:

"error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt"


On Fri, Aug 16, 2013 at 3:28 AM, Ben Laurie  wrote:

> Try
>
> write_data( file_, data, strlen(data) + 1, "mykey");
>
>
>
> On 16 August 2013 03:34, Ztatik Light  wrote:
>
>> ps, yes, line 29 is a mistake and should read: char new_filename[strlen(
>> filename ) + 5];
>>
>> But even with that fix i get the same results
>>
>>
>> On Fri, Aug 16, 2013 at 2:27 AM, Ztatik Light wrote:
>>
>>> maybe not - still confused
>>>
>>>
>>> On Fri, Aug 16, 2013 at 2:21 AM, Ztatik Light wrote:
>>>
 strange i think it has something to do with me using "rb" and "wb"
 instead of "r" and "w"...


 On Fri, Aug 16, 2013 at 2:14 AM, Ztatik Light 
 wrote:

> So, I'm having a really weird issue... i'm trying simple file
> encryption/decryption with BIO_*, but if the encrypted file is in a
> subdirectory.. i get garbage data,
>
> I'll post the code i'm using, with a brief elaboration on how i'm
> using it and what behaviour i'm getting:
>
> ///
>
> /*
>>
>>   Example of ssl read and write to a file
>>
>>
>>>   gcc ssl_write_read.c -lssl
>>
>>   ./a.out
>>
>>
>>>
>>> */
>>
>>
>>>
>>>
>>> #include 
>>
>> #include 
>>
>> #include 
>>
>> #include 
>>
>> #include 
>>
>>
>>> int read_whole_file( char* filename, char** data ){
>>
>>  FILE* file = fopen( filename, "rb" );
>>
>>  fseek( file, 0, SEEK_END );
>>
>>  long fileSize = ftell( file );
>>
>>  rewind( file );
>>
>>  *data = malloc( fileSize );
>>
>>  fread( *data, fileSize, 1, file );
>>
>>  fclose( file );
>>
>>  return fileSize;
>>
>> }
>>
>> void encrypt_file( char* filename ){
>>
>> char new_filename[strlen( filename + 4 )];
>>
>>  strcpy( new_filename, filename );
>>
>>  strcat( new_filename, ".enc" );
>>
>>  char* data;
>>
>>  int fileSize = read_whole_file( filename, &data );
>>
>>  write_data( new_filename, data, fileSize, (unsigned char*)"mykey" );
>>
>>  free( data );
>>
>> }
>>
>>
>>> int write_data(const char *filename, char *out, int len, unsigned
>>> char *key)
>>
>> {
>>
>>   int total, written;
>>
>>   BIO *cipher, *buffer, *file;
>>
>>
>>
>>   /* Create a buffered file BIO for writing */
>>
>>   file = BIO_new_file(filename, "wb");
>>
>>   if (!file)
>>
>> return 0;
>>
>>
>>
>>   /* Create a buffering filter BIO to buffer writes to the file */
>>
>>   buffer = BIO_new(BIO_f_buffer(  ));
>>
>>
>>
>>   /* Create a base64 encoding filter BIO */
>>
>> //  b64 = BIO_new(BIO_f_base64(  ));
>>
>>
>>
>>   /* Create the cipher filter BIO and set the key.  The last
>>> parameter of
>>
>>  BIO_set_cipher is 1 for encryption and 0 for decryption */
>>
>>   cipher = BIO_new(BIO_f_cipher(  ));
>>
>>   BIO_set_cipher(cipher, EVP_des_ede3_cbc(  ), key, NULL, 1);
>>
>>
>>
>>   /* Assemble the BIO chain to be in the order cipher-b64-buffer-file
>>> */
>>
>> //  BIO_push(cipher, b64);
>>
>> //  BIO_push(b64, buffer);
>>
>> BIO_push(cipher,buffer);
>>
>>   BIO_push(buffer, file);
>>
>>
>>>   /* This loop writes the data to the file.  It checks for errors as
>>> if the
>>
>>  underlying file were non-blocking */
>>
>>   for (total = 0;  total < len;  total += written)
>>
>> {
>>
>>   if ((written = BIO_write(cipher, out + total, len - total)) <=
>>> 0)
>>
>> {
>>
>>   if (BIO_should_retry(cipher))
>>
>> {
>>
>>   written = 0;
>>
>>   continue;
>>
>> }
>>
>>   break;
>>
>> }
>>
>> }
>>
>>
>>
>>   /* Ensure all of our data is pushed all the way to the file */
>>
>>   BIO_flush(cipher);
>>
>>
>>
>>   BIO_free_all(cipher);
>>
>> }
>>
>>
>>> BIO* decrypt_open( const char *filename, unsigned char *key ){
>>
>>   int total, written;
>>
>>   BIO *cipher, *buffer, *file;
>>
>>   //char *b = malloc(len);
>>
>>
>>
>>   /* Create a buffered file BIO for reading */
>>
>>   file = BIO_new_file(filename, "rb");
>>
>>   if (!file)
>>
>> return 0;
>>
>>
>>
>>   /* Create a buffering filter BIO to buffer writes to the file */
>>
>>   buffer = BIO_new(BIO_f_buffer(  ));
>>
>>
>>
>>   /* Create a base64 encoding filter BIO */
>>
>> /

Re: weird bug

[Ben Laurie]

Try

write_data( file_, data, strlen(data) + 1, "mykey");



On 16 August 2013 03:34, Ztatik Light  wrote:

> ps, yes, line 29 is a mistake and should read: char new_filename[strlen(
> filename ) + 5];
>
> But even with that fix i get the same results
>
>
> On Fri, Aug 16, 2013 at 2:27 AM, Ztatik Light wrote:
>
>> maybe not - still confused
>>
>>
>> On Fri, Aug 16, 2013 at 2:21 AM, Ztatik Light wrote:
>>
>>> strange i think it has something to do with me using "rb" and "wb"
>>> instead of "r" and "w"...
>>>
>>>
>>> On Fri, Aug 16, 2013 at 2:14 AM, Ztatik Light wrote:
>>>
 So, I'm having a really weird issue... i'm trying simple file
 encryption/decryption with BIO_*, but if the encrypted file is in a
 subdirectory.. i get garbage data,

 I'll post the code i'm using, with a brief elaboration on how i'm using
 it and what behaviour i'm getting:

 ///

 /*
>
>   Example of ssl read and write to a file
>
>
>>   gcc ssl_write_read.c -lssl
>
>   ./a.out
>
>
>>
>> */
>
>
>>
>>
>> #include 
>
> #include 
>
> #include 
>
> #include 
>
> #include 
>
>
>> int read_whole_file( char* filename, char** data ){
>
>  FILE* file = fopen( filename, "rb" );
>
>  fseek( file, 0, SEEK_END );
>
>  long fileSize = ftell( file );
>
>  rewind( file );
>
>  *data = malloc( fileSize );
>
>  fread( *data, fileSize, 1, file );
>
>  fclose( file );
>
>  return fileSize;
>
> }
>
> void encrypt_file( char* filename ){
>
> char new_filename[strlen( filename + 4 )];
>
>  strcpy( new_filename, filename );
>
>  strcat( new_filename, ".enc" );
>
>  char* data;
>
>  int fileSize = read_whole_file( filename, &data );
>
>  write_data( new_filename, data, fileSize, (unsigned char*)"mykey" );
>
>  free( data );
>
> }
>
>
>> int write_data(const char *filename, char *out, int len, unsigned
>> char *key)
>
> {
>
>   int total, written;
>
>   BIO *cipher, *buffer, *file;
>
>
>
>   /* Create a buffered file BIO for writing */
>
>   file = BIO_new_file(filename, "wb");
>
>   if (!file)
>
> return 0;
>
>
>
>   /* Create a buffering filter BIO to buffer writes to the file */
>
>   buffer = BIO_new(BIO_f_buffer(  ));
>
>
>
>   /* Create a base64 encoding filter BIO */
>
> //  b64 = BIO_new(BIO_f_base64(  ));
>
>
>
>   /* Create the cipher filter BIO and set the key.  The last parameter
>> of
>
>  BIO_set_cipher is 1 for encryption and 0 for decryption */
>
>   cipher = BIO_new(BIO_f_cipher(  ));
>
>   BIO_set_cipher(cipher, EVP_des_ede3_cbc(  ), key, NULL, 1);
>
>
>
>   /* Assemble the BIO chain to be in the order cipher-b64-buffer-file
>> */
>
> //  BIO_push(cipher, b64);
>
> //  BIO_push(b64, buffer);
>
> BIO_push(cipher,buffer);
>
>   BIO_push(buffer, file);
>
>
>>   /* This loop writes the data to the file.  It checks for errors as
>> if the
>
>  underlying file were non-blocking */
>
>   for (total = 0;  total < len;  total += written)
>
> {
>
>   if ((written = BIO_write(cipher, out + total, len - total)) <= 0)
>
> {
>
>   if (BIO_should_retry(cipher))
>
> {
>
>   written = 0;
>
>   continue;
>
> }
>
>   break;
>
> }
>
> }
>
>
>
>   /* Ensure all of our data is pushed all the way to the file */
>
>   BIO_flush(cipher);
>
>
>
>   BIO_free_all(cipher);
>
> }
>
>
>> BIO* decrypt_open( const char *filename, unsigned char *key ){
>
>   int total, written;
>
>   BIO *cipher, *buffer, *file;
>
>   //char *b = malloc(len);
>
>
>
>   /* Create a buffered file BIO for reading */
>
>   file = BIO_new_file(filename, "rb");
>
>   if (!file)
>
> return 0;
>
>
>
>   /* Create a buffering filter BIO to buffer writes to the file */
>
>   buffer = BIO_new(BIO_f_buffer(  ));
>
>
>
>   /* Create a base64 encoding filter BIO */
>
> //  b64 = BIO_new(BIO_f_base64(  ));
>
>
>
>   /* Create the cipher filter BIO and set the key.  The last parameter
>> of
>
>  BIO_set_cipher is 1 for encryption and 0 for decryption */
>
>   cipher = BIO_new(BIO_f_cipher(  ));
>
>   BIO_set_cipher(cipher, EVP_des_ede3_cbc(  ), key, NULL, 0);
>
>
>
>   /* Assemble the BIO chain to be in the order cipher-b64-buffer-file
>> */
>

How to securely encrypt identical files to identical ciphertext?

[Unga]

Hi all

I have a requirement to encrypt files, in such a way identical files should 
generate identical ciphertexts. 

I plan to use aes-256-cbc cipher with 128-byte long non-guessable password per 
input file. Identical input files will be provided with identical passwords.

1. Is it no salt the way forward for me?

2. How many rounds are recommended for EVP_BytesToKey() in my case?

Many thanks in advance.

Best regards
Unga

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

Re: DLL hell

[Viktor Dukhovni]

On Fri, Aug 16, 2013 at 07:17:22AM -0700, Thomas J. Hruska wrote:

> I think a lot of the init logic heralds from the original SSLeay
> days. There seems to be intent that initialization is supposed to
> happen in main() in the application and libraries shouldn't be
> calling initialization routines in OpenSSL.

This is a big problem, when main() has no knowledge of OpenSSL,
rather OpenSSL is used indirectly via an intermediate library, that
may even be dynamically loaded (e.g. Java dynamically loading
GSSAPI, with Heimdal's GSS library using OpenSSL).

Now it is certainly not appropriate for other libraries to call
OpenSSL one-time initialization functions.  The result is a mess.

> However, I agree that all the init logic for the library should be
> handled automatically and transparently in a thread-safe manner.

Therefore, it is probably time to consider moving the OpenSSL
library initialization code into OpenSSL itself, with the set of
ciphers and digests to initialize by default as well as the thread
locking mechanism chosen at compile time.

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

Re: DLL hell

[Thomas J. Hruska]

On 8/15/2013 10:24 AM, Nico Williams wrote:

Hi, I'm sorry if this has all been discussed extensively before.  A
brief search for "DLL hell" in the archives turns up disappointingly
(and surprisingly) little.  I do see a thread with messages from my
erstwhile colleagues at Sun/Oracle, so I know it's been discussed,
e.g., here: http://www.mail-archive.com/openssl-dev@openssl.org/msg27453.html
.  Recent developments, like Android's failure to properly initialize
OpenSSL's PRNG make me think it's time to table (in the British sense)
the issue once more.

To summarize the rest of this long post (please forgive me):


I think a lot of the init logic heralds from the original SSLeay days. 
There seems to be intent that initialization is supposed to happen in 
main() in the application and libraries shouldn't be calling 
initialization routines in OpenSSL.


However, I agree that all the init logic for the library should be 
handled automatically and transparently in a thread-safe manner.


--
Thomas Hruska
Shining Light Productions

Home of BMP2AVI and Win32 OpenSSL.
http://www.slproweb.com/
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

weird bug

[Ztatik Light]

So, I'm having a really weird issue... i'm trying simple file
encryption/decryption with BIO_*, but if the encrypted file is in a
subdirectory.. i get garbage data,

I'll post the code i'm using, with a brief elaboration on how i'm using it
and what behaviour i'm getting:

///

/*
>
>   Example of ssl read and write to a file
>
>
>>   gcc ssl_write_read.c -lssl
>
>   ./a.out
>
>
>>
>> */
>
>
>>
>>
>> #include 
>
> #include 
>
> #include 
>
> #include 
>
> #include 
>
>
>> int read_whole_file( char* filename, char** data ){
>
> FILE* file = fopen( filename, "rb" );
>
> fseek( file, 0, SEEK_END );
>
> long fileSize = ftell( file );
>
> rewind( file );
>
> *data = malloc( fileSize );
>
> fread( *data, fileSize, 1, file );
>
> fclose( file );
>
> return fileSize;
>
> }
>
> void encrypt_file( char* filename ){
>
> char new_filename[strlen( filename + 4 )];
>
> strcpy( new_filename, filename );
>
> strcat( new_filename, ".enc" );
>
> char* data;
>
> int fileSize = read_whole_file( filename, &data );
>
> write_data( new_filename, data, fileSize, (unsigned char*)"mykey" );
>
> free( data );
>
> }
>
>
>> int write_data(const char *filename, char *out, int len, unsigned char
>> *key)
>
> {
>
>   int total, written;
>
>   BIO *cipher, *buffer, *file;
>
>
>
>   /* Create a buffered file BIO for writing */
>
>   file = BIO_new_file(filename, "wb");
>
>   if (!file)
>
> return 0;
>
>
>
>   /* Create a buffering filter BIO to buffer writes to the file */
>
>   buffer = BIO_new(BIO_f_buffer(  ));
>
>
>
>   /* Create a base64 encoding filter BIO */
>
> //  b64 = BIO_new(BIO_f_base64(  ));
>
>
>
>   /* Create the cipher filter BIO and set the key.  The last parameter of
>
>  BIO_set_cipher is 1 for encryption and 0 for decryption */
>
>   cipher = BIO_new(BIO_f_cipher(  ));
>
>   BIO_set_cipher(cipher, EVP_des_ede3_cbc(  ), key, NULL, 1);
>
>
>
>   /* Assemble the BIO chain to be in the order cipher-b64-buffer-file */
>
> //  BIO_push(cipher, b64);
>
> //  BIO_push(b64, buffer);
>
> BIO_push(cipher,buffer);
>
>   BIO_push(buffer, file);
>
>
>>   /* This loop writes the data to the file.  It checks for errors as if
>> the
>
>  underlying file were non-blocking */
>
>   for (total = 0;  total < len;  total += written)
>
> {
>
>   if ((written = BIO_write(cipher, out + total, len - total)) <= 0)
>
> {
>
>   if (BIO_should_retry(cipher))
>
> {
>
>   written = 0;
>
>   continue;
>
> }
>
>   break;
>
> }
>
> }
>
>
>
>   /* Ensure all of our data is pushed all the way to the file */
>
>   BIO_flush(cipher);
>
>
>
>   BIO_free_all(cipher);
>
> }
>
>
>> BIO* decrypt_open( const char *filename, unsigned char *key ){
>
>   int total, written;
>
>   BIO *cipher, *buffer, *file;
>
>   //char *b = malloc(len);
>
>
>
>   /* Create a buffered file BIO for reading */
>
>   file = BIO_new_file(filename, "rb");
>
>   if (!file)
>
> return 0;
>
>
>
>   /* Create a buffering filter BIO to buffer writes to the file */
>
>   buffer = BIO_new(BIO_f_buffer(  ));
>
>
>
>   /* Create a base64 encoding filter BIO */
>
> //  b64 = BIO_new(BIO_f_base64(  ));
>
>
>
>   /* Create the cipher filter BIO and set the key.  The last parameter of
>
>  BIO_set_cipher is 1 for encryption and 0 for decryption */
>
>   cipher = BIO_new(BIO_f_cipher(  ));
>
>   BIO_set_cipher(cipher, EVP_des_ede3_cbc(  ), key, NULL, 0);
>
>
>
>   /* Assemble the BIO chain to be in the order cipher-b64-buffer-file */
>
> //  BIO_push(cipher, b64);
>
> //  BIO_push(b64, buffer);
>
> BIO_push(cipher,buffer);
>
>   BIO_push(buffer, file);
>
>   return cipher;
>
> }
>
> char* decrypt_read( BIO* cipher, int len, char* b ){
>
>   int total, written;
>
>
>> // char b[len + 1];
>
>   for (total = 0;  total < len;  total += written)
>
> {
>
>   if ((written = BIO_read(cipher, b, len - total)) <= 0)
>
> {
>
>   if (BIO_should_retry(cipher))
>
> {
>
>   written = 0;
>
>   continue;
>
> }
>
>   break;
>
> }
>
> }
>
>
>
>   b[total] = '\0';
>
>
>
>   return b;
>
> }
>
>
>> int main(void)
>
> {
>
> //chdir("subdirectory");
>
> char *file_="test.txt";
>
> char* data = "howdy\n";
>
> write_data( file_, data, strlen(data), "mykey");
>
>
>> BIO* cipher = decrypt_open( file_, (unsigned char*)"mykey" );
>
> char b[99];
>
> decrypt_read( cipher, 99, b );
>
> BIO_flush( cipher );
>
> BIO_free_all( cipher );
>
> printf(">%s\n",b);
>
>
>> //char* test="plain.txt";
>
> //encrypt_file(test);
>
>
>> }
>
>
///

1. So, first run creates and writes encrypted file "test.txt" and then
decrypts and prints out the contents, "howdy",

2. Now, comment out line 141 // write_data( ... re-run to verify "howdy",
works fine

3. make directory "temp", move "test.txt" into "temp" and change line 139
to reflect that: char *file_="temp/test.txt";.. re-run - I get no results ??

4. Even more weird: ch

Re: weird bug

[Ztatik Light]

ps, yes, line 29 is a mistake and should read: char new_filename[strlen(
filename ) + 5];

But even with that fix i get the same results


On Fri, Aug 16, 2013 at 2:27 AM, Ztatik Light wrote:

> maybe not - still confused
>
>
> On Fri, Aug 16, 2013 at 2:21 AM, Ztatik Light wrote:
>
>> strange i think it has something to do with me using "rb" and "wb"
>> instead of "r" and "w"...
>>
>>
>> On Fri, Aug 16, 2013 at 2:14 AM, Ztatik Light wrote:
>>
>>> So, I'm having a really weird issue... i'm trying simple file
>>> encryption/decryption with BIO_*, but if the encrypted file is in a
>>> subdirectory.. i get garbage data,
>>>
>>> I'll post the code i'm using, with a brief elaboration on how i'm using
>>> it and what behaviour i'm getting:
>>>
>>> ///
>>>
>>> /*

   Example of ssl read and write to a file


>   gcc ssl_write_read.c -lssl

   ./a.out


>
> */


>
>
> #include 

 #include 

 #include 

 #include 

 #include 


> int read_whole_file( char* filename, char** data ){

  FILE* file = fopen( filename, "rb" );

  fseek( file, 0, SEEK_END );

  long fileSize = ftell( file );

  rewind( file );

  *data = malloc( fileSize );

  fread( *data, fileSize, 1, file );

  fclose( file );

  return fileSize;

 }

 void encrypt_file( char* filename ){

 char new_filename[strlen( filename + 4 )];

  strcpy( new_filename, filename );

  strcat( new_filename, ".enc" );

  char* data;

  int fileSize = read_whole_file( filename, &data );

  write_data( new_filename, data, fileSize, (unsigned char*)"mykey" );

  free( data );

 }


> int write_data(const char *filename, char *out, int len, unsigned char
> *key)

 {

   int total, written;

   BIO *cipher, *buffer, *file;



   /* Create a buffered file BIO for writing */

   file = BIO_new_file(filename, "wb");

   if (!file)

 return 0;



   /* Create a buffering filter BIO to buffer writes to the file */

   buffer = BIO_new(BIO_f_buffer(  ));



   /* Create a base64 encoding filter BIO */

 //  b64 = BIO_new(BIO_f_base64(  ));



   /* Create the cipher filter BIO and set the key.  The last parameter
> of

  BIO_set_cipher is 1 for encryption and 0 for decryption */

   cipher = BIO_new(BIO_f_cipher(  ));

   BIO_set_cipher(cipher, EVP_des_ede3_cbc(  ), key, NULL, 1);



   /* Assemble the BIO chain to be in the order cipher-b64-buffer-file */

 //  BIO_push(cipher, b64);

 //  BIO_push(b64, buffer);

 BIO_push(cipher,buffer);

   BIO_push(buffer, file);


>   /* This loop writes the data to the file.  It checks for errors as
> if the

  underlying file were non-blocking */

   for (total = 0;  total < len;  total += written)

 {

   if ((written = BIO_write(cipher, out + total, len - total)) <= 0)

 {

   if (BIO_should_retry(cipher))

 {

   written = 0;

   continue;

 }

   break;

 }

 }



   /* Ensure all of our data is pushed all the way to the file */

   BIO_flush(cipher);



   BIO_free_all(cipher);

 }


> BIO* decrypt_open( const char *filename, unsigned char *key ){

   int total, written;

   BIO *cipher, *buffer, *file;

   //char *b = malloc(len);



   /* Create a buffered file BIO for reading */

   file = BIO_new_file(filename, "rb");

   if (!file)

 return 0;



   /* Create a buffering filter BIO to buffer writes to the file */

   buffer = BIO_new(BIO_f_buffer(  ));



   /* Create a base64 encoding filter BIO */

 //  b64 = BIO_new(BIO_f_base64(  ));



   /* Create the cipher filter BIO and set the key.  The last parameter
> of

  BIO_set_cipher is 1 for encryption and 0 for decryption */

   cipher = BIO_new(BIO_f_cipher(  ));

   BIO_set_cipher(cipher, EVP_des_ede3_cbc(  ), key, NULL, 0);



   /* Assemble the BIO chain to be in the order cipher-b64-buffer-file */

 //  BIO_push(cipher, b64);

 //  BIO_push(b64, buffer);

 BIO_push(cipher,buffer);

   BIO_push(buffer, file);

   return cipher;

 }

 char* decrypt_read( BIO* cipher, int len, char* b ){

   int total, written;


> // char b[len + 1];

   for (total = 0;  total < len;  total += 

Re: OSX Open SSL Usage question

[Ztatik Light]

>From stackoverflow:

"These hash values will comes from the Subject DN of each CA certificate
(since the aim is to look for a CA certificate with the subject matching
the issuer of the certificate to verify). You can either usec_rehash as
documented, or get the Subject DN's hash using openssl x509 -subject_hash
-noout -in cacert.pem and rename the file/link accordingly."


On Thu, Aug 15, 2013 at 12:01 PM, Andrew H  wrote:

> I have two version of OpenSSL on my OSX file system, the default 0.9.8r
> and 1.0.1e.
> For the later I'm having trouble getting the syntax of the command
> correct, I think.
>
> When I used this (in 1.0.1e's directory, /opt/localbin):
> ./openssl s_client -connect foo.foo.foo.foo:443 ( replace the foo's ).
> I get responses that included the Cipher is NONE and 'unable to get local
> issuer certificate' messages.
>
> Without the ./, using the default openssl, this works fine, the cipher is
> populated and no local issuer messages.
>
> I tried variations of the CApath argument with no success:
> -CApath /System/Library/OpenSSL/certs/
> That's the system path from 'openssl version -d'
> I messed around with similar values in the verify argument.
> There's obviously a fundamental misunderstanding on my part regarding the
> proper usage of these arguments.
>
> Tips appreciated.
>
> Andrew
>

Re: weird bug

[Ztatik Light]

maybe not - still confused


On Fri, Aug 16, 2013 at 2:21 AM, Ztatik Light wrote:

> strange i think it has something to do with me using "rb" and "wb" instead
> of "r" and "w"...
>
>
> On Fri, Aug 16, 2013 at 2:14 AM, Ztatik Light wrote:
>
>> So, I'm having a really weird issue... i'm trying simple file
>> encryption/decryption with BIO_*, but if the encrypted file is in a
>> subdirectory.. i get garbage data,
>>
>> I'll post the code i'm using, with a brief elaboration on how i'm using
>> it and what behaviour i'm getting:
>>
>> ///
>>
>> /*
>>>
>>>   Example of ssl read and write to a file
>>>
>>>
   gcc ssl_write_read.c -lssl
>>>
>>>   ./a.out
>>>
>>>

 */
>>>
>>>


 #include 
>>>
>>> #include 
>>>
>>> #include 
>>>
>>> #include 
>>>
>>> #include 
>>>
>>>
 int read_whole_file( char* filename, char** data ){
>>>
>>>  FILE* file = fopen( filename, "rb" );
>>>
>>>  fseek( file, 0, SEEK_END );
>>>
>>>  long fileSize = ftell( file );
>>>
>>>  rewind( file );
>>>
>>>  *data = malloc( fileSize );
>>>
>>>  fread( *data, fileSize, 1, file );
>>>
>>>  fclose( file );
>>>
>>>  return fileSize;
>>>
>>> }
>>>
>>> void encrypt_file( char* filename ){
>>>
>>> char new_filename[strlen( filename + 4 )];
>>>
>>>  strcpy( new_filename, filename );
>>>
>>>  strcat( new_filename, ".enc" );
>>>
>>>  char* data;
>>>
>>>  int fileSize = read_whole_file( filename, &data );
>>>
>>>  write_data( new_filename, data, fileSize, (unsigned char*)"mykey" );
>>>
>>>  free( data );
>>>
>>> }
>>>
>>>
 int write_data(const char *filename, char *out, int len, unsigned char
 *key)
>>>
>>> {
>>>
>>>   int total, written;
>>>
>>>   BIO *cipher, *buffer, *file;
>>>
>>>
>>>
>>>   /* Create a buffered file BIO for writing */
>>>
>>>   file = BIO_new_file(filename, "wb");
>>>
>>>   if (!file)
>>>
>>> return 0;
>>>
>>>
>>>
>>>   /* Create a buffering filter BIO to buffer writes to the file */
>>>
>>>   buffer = BIO_new(BIO_f_buffer(  ));
>>>
>>>
>>>
>>>   /* Create a base64 encoding filter BIO */
>>>
>>> //  b64 = BIO_new(BIO_f_base64(  ));
>>>
>>>
>>>
>>>   /* Create the cipher filter BIO and set the key.  The last parameter of
>>>
>>>  BIO_set_cipher is 1 for encryption and 0 for decryption */
>>>
>>>   cipher = BIO_new(BIO_f_cipher(  ));
>>>
>>>   BIO_set_cipher(cipher, EVP_des_ede3_cbc(  ), key, NULL, 1);
>>>
>>>
>>>
>>>   /* Assemble the BIO chain to be in the order cipher-b64-buffer-file */
>>>
>>> //  BIO_push(cipher, b64);
>>>
>>> //  BIO_push(b64, buffer);
>>>
>>> BIO_push(cipher,buffer);
>>>
>>>   BIO_push(buffer, file);
>>>
>>>
   /* This loop writes the data to the file.  It checks for errors as if
 the
>>>
>>>  underlying file were non-blocking */
>>>
>>>   for (total = 0;  total < len;  total += written)
>>>
>>> {
>>>
>>>   if ((written = BIO_write(cipher, out + total, len - total)) <= 0)
>>>
>>> {
>>>
>>>   if (BIO_should_retry(cipher))
>>>
>>> {
>>>
>>>   written = 0;
>>>
>>>   continue;
>>>
>>> }
>>>
>>>   break;
>>>
>>> }
>>>
>>> }
>>>
>>>
>>>
>>>   /* Ensure all of our data is pushed all the way to the file */
>>>
>>>   BIO_flush(cipher);
>>>
>>>
>>>
>>>   BIO_free_all(cipher);
>>>
>>> }
>>>
>>>
 BIO* decrypt_open( const char *filename, unsigned char *key ){
>>>
>>>   int total, written;
>>>
>>>   BIO *cipher, *buffer, *file;
>>>
>>>   //char *b = malloc(len);
>>>
>>>
>>>
>>>   /* Create a buffered file BIO for reading */
>>>
>>>   file = BIO_new_file(filename, "rb");
>>>
>>>   if (!file)
>>>
>>> return 0;
>>>
>>>
>>>
>>>   /* Create a buffering filter BIO to buffer writes to the file */
>>>
>>>   buffer = BIO_new(BIO_f_buffer(  ));
>>>
>>>
>>>
>>>   /* Create a base64 encoding filter BIO */
>>>
>>> //  b64 = BIO_new(BIO_f_base64(  ));
>>>
>>>
>>>
>>>   /* Create the cipher filter BIO and set the key.  The last parameter of
>>>
>>>  BIO_set_cipher is 1 for encryption and 0 for decryption */
>>>
>>>   cipher = BIO_new(BIO_f_cipher(  ));
>>>
>>>   BIO_set_cipher(cipher, EVP_des_ede3_cbc(  ), key, NULL, 0);
>>>
>>>
>>>
>>>   /* Assemble the BIO chain to be in the order cipher-b64-buffer-file */
>>>
>>> //  BIO_push(cipher, b64);
>>>
>>> //  BIO_push(b64, buffer);
>>>
>>> BIO_push(cipher,buffer);
>>>
>>>   BIO_push(buffer, file);
>>>
>>>   return cipher;
>>>
>>> }
>>>
>>> char* decrypt_read( BIO* cipher, int len, char* b ){
>>>
>>>   int total, written;
>>>
>>>
 // char b[len + 1];
>>>
>>>   for (total = 0;  total < len;  total += written)
>>>
>>> {
>>>
>>>   if ((written = BIO_read(cipher, b, len - total)) <= 0)
>>>
>>> {
>>>
>>>   if (BIO_should_retry(cipher))
>>>
>>> {
>>>
>>>   written = 0;
>>>
>>>   continue;
>>>
>>> }
>>>
>>>   break;
>>>
>>> }
>>>
>>> }
>>>
>>>
>>>
>>>   b[total] = '\0';
>>>
>>>
>>>
>>>   return b;
>>>
>>> }
>>>
>>>
 int main(void)
>>>
>>> {
>>>
>>> //chdir("subdirectory");
>>>
>>> char *f

Re: weird bug

[Ztatik Light]

strange i think it has something to do with me using "rb" and "wb" instead
of "r" and "w"...


On Fri, Aug 16, 2013 at 2:14 AM, Ztatik Light wrote:

> So, I'm having a really weird issue... i'm trying simple file
> encryption/decryption with BIO_*, but if the encrypted file is in a
> subdirectory.. i get garbage data,
>
> I'll post the code i'm using, with a brief elaboration on how i'm using it
> and what behaviour i'm getting:
>
> ///
>
> /*
>>
>>   Example of ssl read and write to a file
>>
>>
>>>   gcc ssl_write_read.c -lssl
>>
>>   ./a.out
>>
>>
>>>
>>> */
>>
>>
>>>
>>>
>>> #include 
>>
>> #include 
>>
>> #include 
>>
>> #include 
>>
>> #include 
>>
>>
>>> int read_whole_file( char* filename, char** data ){
>>
>>  FILE* file = fopen( filename, "rb" );
>>
>>  fseek( file, 0, SEEK_END );
>>
>>  long fileSize = ftell( file );
>>
>>  rewind( file );
>>
>>  *data = malloc( fileSize );
>>
>>  fread( *data, fileSize, 1, file );
>>
>>  fclose( file );
>>
>>  return fileSize;
>>
>> }
>>
>> void encrypt_file( char* filename ){
>>
>> char new_filename[strlen( filename + 4 )];
>>
>>  strcpy( new_filename, filename );
>>
>>  strcat( new_filename, ".enc" );
>>
>>  char* data;
>>
>>  int fileSize = read_whole_file( filename, &data );
>>
>>  write_data( new_filename, data, fileSize, (unsigned char*)"mykey" );
>>
>>  free( data );
>>
>> }
>>
>>
>>> int write_data(const char *filename, char *out, int len, unsigned char
>>> *key)
>>
>> {
>>
>>   int total, written;
>>
>>   BIO *cipher, *buffer, *file;
>>
>>
>>
>>   /* Create a buffered file BIO for writing */
>>
>>   file = BIO_new_file(filename, "wb");
>>
>>   if (!file)
>>
>> return 0;
>>
>>
>>
>>   /* Create a buffering filter BIO to buffer writes to the file */
>>
>>   buffer = BIO_new(BIO_f_buffer(  ));
>>
>>
>>
>>   /* Create a base64 encoding filter BIO */
>>
>> //  b64 = BIO_new(BIO_f_base64(  ));
>>
>>
>>
>>   /* Create the cipher filter BIO and set the key.  The last parameter of
>>
>>  BIO_set_cipher is 1 for encryption and 0 for decryption */
>>
>>   cipher = BIO_new(BIO_f_cipher(  ));
>>
>>   BIO_set_cipher(cipher, EVP_des_ede3_cbc(  ), key, NULL, 1);
>>
>>
>>
>>   /* Assemble the BIO chain to be in the order cipher-b64-buffer-file */
>>
>> //  BIO_push(cipher, b64);
>>
>> //  BIO_push(b64, buffer);
>>
>> BIO_push(cipher,buffer);
>>
>>   BIO_push(buffer, file);
>>
>>
>>>   /* This loop writes the data to the file.  It checks for errors as if
>>> the
>>
>>  underlying file were non-blocking */
>>
>>   for (total = 0;  total < len;  total += written)
>>
>> {
>>
>>   if ((written = BIO_write(cipher, out + total, len - total)) <= 0)
>>
>> {
>>
>>   if (BIO_should_retry(cipher))
>>
>> {
>>
>>   written = 0;
>>
>>   continue;
>>
>> }
>>
>>   break;
>>
>> }
>>
>> }
>>
>>
>>
>>   /* Ensure all of our data is pushed all the way to the file */
>>
>>   BIO_flush(cipher);
>>
>>
>>
>>   BIO_free_all(cipher);
>>
>> }
>>
>>
>>> BIO* decrypt_open( const char *filename, unsigned char *key ){
>>
>>   int total, written;
>>
>>   BIO *cipher, *buffer, *file;
>>
>>   //char *b = malloc(len);
>>
>>
>>
>>   /* Create a buffered file BIO for reading */
>>
>>   file = BIO_new_file(filename, "rb");
>>
>>   if (!file)
>>
>> return 0;
>>
>>
>>
>>   /* Create a buffering filter BIO to buffer writes to the file */
>>
>>   buffer = BIO_new(BIO_f_buffer(  ));
>>
>>
>>
>>   /* Create a base64 encoding filter BIO */
>>
>> //  b64 = BIO_new(BIO_f_base64(  ));
>>
>>
>>
>>   /* Create the cipher filter BIO and set the key.  The last parameter of
>>
>>  BIO_set_cipher is 1 for encryption and 0 for decryption */
>>
>>   cipher = BIO_new(BIO_f_cipher(  ));
>>
>>   BIO_set_cipher(cipher, EVP_des_ede3_cbc(  ), key, NULL, 0);
>>
>>
>>
>>   /* Assemble the BIO chain to be in the order cipher-b64-buffer-file */
>>
>> //  BIO_push(cipher, b64);
>>
>> //  BIO_push(b64, buffer);
>>
>> BIO_push(cipher,buffer);
>>
>>   BIO_push(buffer, file);
>>
>>   return cipher;
>>
>> }
>>
>> char* decrypt_read( BIO* cipher, int len, char* b ){
>>
>>   int total, written;
>>
>>
>>> // char b[len + 1];
>>
>>   for (total = 0;  total < len;  total += written)
>>
>> {
>>
>>   if ((written = BIO_read(cipher, b, len - total)) <= 0)
>>
>> {
>>
>>   if (BIO_should_retry(cipher))
>>
>> {
>>
>>   written = 0;
>>
>>   continue;
>>
>> }
>>
>>   break;
>>
>> }
>>
>> }
>>
>>
>>
>>   b[total] = '\0';
>>
>>
>>
>>   return b;
>>
>> }
>>
>>
>>> int main(void)
>>
>> {
>>
>> //chdir("subdirectory");
>>
>> char *file_="test.txt";
>>
>>  char* data = "howdy\n";
>>
>>  write_data( file_, data, strlen(data), "mykey");
>>
>>
>>>  BIO* cipher = decrypt_open( file_, (unsigned char*)"mykey" );
>>
>>  char b[99];
>>
>>  decrypt_read( cipher, 99, b );
>>
>>  BIO_flush( cipher );
>>
>>  BIO_free_all( cipher );
>>
>>  printf(">%s\n",b);
>>
>>
>>> //char* test="plain.txt";
>>
>>

OSX Open SSL Usage question

[Andrew H]

I have two version of OpenSSL on my OSX file system, the default 0.9.8r and 
1.0.1e.For the later I'm having trouble getting the syntax of the command 
correct, I think.
When I used this (in 1.0.1e's directory, /opt/localbin):./openssl s_client 
-connect foo.foo.foo.foo:443 ( replace the foo's ).I get responses that 
included the Cipher is NONE and 'unable to get local issuer certificate' 
messages.
Without the ./, using the default openssl, this works fine, the cipher is 
populated and no local issuer messages.
I tried variations of the CApath argument with no success:-CApath 
/System/Library/OpenSSL/certs/ That's the system path from 'openssl version 
-d'I messed around with similar values in the verify argument.  There's 
obviously a fundamental misunderstanding on my part regarding the proper usage 
of these arguments.
Tips appreciated.
Andrew