Re: DLL hell
On Aug 15, 2013, at 10:38 PM, Nico Williams wrote: Hmm, I've only read the article linked from there: http://android-developers.blogspot.com/2013/08/some-securerandom-thoughts.html Yeah, that's the only place I've seen it, and then the Google+ thread I linked to is essentially the comment area for that post. We (meaning those of us commenting in the thread) haven't gotten any official answer from Google, but Nikolay Elenkov has been very helpful in reconstructing what seems to be happening. We've exchanged a few more posts this evening, and it appears that what's happening is that OpenSSL is correctly self-seeding when system_server starts, but then system_server forks (without execing) to start multiple processes, and these processes are producing the same random sequence. It's not yet entirely clear why, since the OpenSSL source code looks like it's trying to be fork-safe, but it appears that somehow in practice it's not succeeding. I'll take a look. For now it seems there should be no need to set any thread-related callbacks, no? Or if they are needed, we should make them no-ops on OSes with thread libraries. Threading callbacks are currently needed for any application that isn't single threaded. (The situation is still the same as what's covered in the 2002 O'Reilly book, Network Security with OpenSSL. It has some sample code for setting them up on Windows and pthreads.) I totally agree with you that I'd love to see support for at least pthreads and Windows threads baked into OpenSSL, much like libevent does, for example. But I suspect that convincing the OpenSSL developers will be an uphill battle. (Just to be clear about my role: I'm an OpenSSL user, an occasional contributor to the OpenSSL wiki, and also one of several admins on the wiki, simply because I was interested and volunteered. But I'm not an OpenSSL developer, nor do I have a direct line to any of the developers. Nor do I speak for anyone but myself. So this is just me throwing opinions and speculation from the peanut gallery.) I think that a crypto library should have no worse initialization/finalization/thread safety/fork safety semantics than libpkcs11 in Solaris/Illumos, which: a) thread-safely ref-counts C_Initialize()/C_Finalize() calls, b) leaves locking around objects to the app, c) re-initializes (and loses all objects) on the child-side of fork(), d) no thread/lock callback setters. (It's necessary to finalize all objects that refer to sessions for crypto coprocessors, TPMs, tokens, as well as any other stateful objects on the child side of fork(), either that or establish new sessions. It shouldn't be necessary to finalize key objects, say, but hey, it's what PKCS#11 requires.) Better yet: implied initialization (using pthread_once()). I'm in total agreement with you on that, although even libraries that I consider pretty good in that regard, like libevent and GnuTLS, don't quite achieve that. A lot of people seem to love static linking. There are problems with dynamic linking, to be sure, but static linking with dynamic dlopen() is insane, and anyways, static linking unfortunately means having to keep track of total dependencies at the program link-edit stage, which is also basically insane (though at least that could be fixed). Agree. And yeah, I hadn't been thinking about static libc. OS X, at least, has the (mostly) nice property that libc (called libSystem) can't be static. 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. 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 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. --Patrick __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
OSX Open SSL Usage question
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
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 ztatik.li...@gmail.comwrote:
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 openssl/bio.h
#include openssl/err.h
#include openssl/rand.h
#include openssl/ssl.h
#include openssl/x509v3.h
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: change line 139 back to just test.txt, and replace
file_ on line 143 with
Re: weird bug
maybe not - still confused
On Fri, Aug 16, 2013 at 2:21 AM, Ztatik Light ztatik.li...@gmail.comwrote:
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 ztatik.li...@gmail.comwrote:
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 openssl/bio.h
#include openssl/err.h
#include openssl/rand.h
#include openssl/ssl.h
#include openssl/x509v3.h
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 ??
Re: OSX Open SSL Usage question
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 andrew_ya...@hotmail.com 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
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 ztatik.li...@gmail.comwrote:
maybe not - still confused
On Fri, Aug 16, 2013 at 2:21 AM, Ztatik Light ztatik.li...@gmail.comwrote:
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 ztatik.li...@gmail.comwrote:
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 openssl/bio.h
#include openssl/err.h
#include openssl/rand.h
#include openssl/ssl.h
#include openssl/x509v3.h
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,
weird bug
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 openssl/bio.h
#include openssl/err.h
#include openssl/rand.h
#include openssl/ssl.h
#include openssl/x509v3.h
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: change line 139 back to just test.txt, and replace
file_ on line 143 with temp/test.txt ... so it reads: BIO* cipher =
decrypt_open( temp/test.txt, (unsigned char*)mykey ); // re-run... now
it works again all of a sudden. BUT - if you comment out line 139 // char
*file_=test.txt;
Re: DLL hell
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
Re: DLL hell
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
How to securely encrypt identical files to identical ciphertext?
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: weird bug
Try
write_data( file_, data, strlen(data) + 1, mykey);
On 16 August 2013 03:34, Ztatik Light ztatik.li...@gmail.com 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 ztatik.li...@gmail.comwrote:
maybe not - still confused
On Fri, Aug 16, 2013 at 2:21 AM, Ztatik Light ztatik.li...@gmail.comwrote:
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 ztatik.li...@gmail.comwrote:
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 openssl/bio.h
#include openssl/err.h
#include openssl/rand.h
#include openssl/ssl.h
#include openssl/x509v3.h
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);
}
Re: weird bug
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 b...@links.org wrote:
Try
write_data( file_, data, strlen(data) + 1, mykey);
On 16 August 2013 03:34, Ztatik Light ztatik.li...@gmail.com 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 ztatik.li...@gmail.comwrote:
maybe not - still confused
On Fri, Aug 16, 2013 at 2:21 AM, Ztatik Light ztatik.li...@gmail.comwrote:
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
ztatik.li...@gmail.comwrote:
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 openssl/bio.h
#include openssl/err.h
#include openssl/rand.h
#include openssl/ssl.h
#include openssl/x509v3.h
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];
Re: weird bug
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 ztatik.li...@gmail.comwrote:
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 b...@links.org wrote:
Try
write_data( file_, data, strlen(data) + 1, mykey);
On 16 August 2013 03:34, Ztatik Light ztatik.li...@gmail.com 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 ztatik.li...@gmail.comwrote:
maybe not - still confused
On Fri, Aug 16, 2013 at 2:21 AM, Ztatik Light
ztatik.li...@gmail.comwrote:
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
ztatik.li...@gmail.comwrote:
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 openssl/bio.h
#include openssl/err.h
#include openssl/rand.h
#include openssl/ssl.h
#include openssl/x509v3.h
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);
RE: weird bug
Ø 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?
On 16-Aug-2013, at 7:49 AM, Unga unga...@yahoo.com 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
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 rs...@akamai.com 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: weird bug
Ø 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?
On 16 August 2013 16:46, Swair Mehta swairme...@gmail.com wrote: On 16-Aug-2013, at 7:49 AM, Unga unga...@yahoo.com 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: DLL hell
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: DLL hell
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: How to securely encrypt identical files to identical ciphertext?
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: How to securely encrypt identical files to identical ciphertext?
- Original Message - From: Swair Mehta swairme...@gmail.com To: openssl-users@openssl.org 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 unga...@yahoo.com 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: weird bug
Ø 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: How to securely encrypt identical files to identical ciphertext?
- Original Message - From: Matt Caswell fr...@baggins.org 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 swairme...@gmail.com wrote: On 16-Aug-2013, at 7:49 AM, Unga unga...@yahoo.com 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: weird bug
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: Displaying cert with ecdsa
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: How to securely encrypt identical files to identical ciphertext?
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)
EVP_DigestSign*() and EVP_DigestVerify*() - help needed
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: EVP_DigestSign*() and EVP_DigestVerify*() - help needed
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
Re: OSX Open SSL Usage question
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 andrew_ya...@hotmail.com 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
Encumbered EC crypto algorithms in openssl?
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 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: How to securely encrypt identical files to identical ciphertext?
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
Re: Encumbered EC crypto algorithms in openssl?
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: Encumbered EC crypto algorithms in openssl?
On Fri, Aug 16, 2013 at 10:40 PM, Nico Williams n...@cryptonector.comwrote: If only we could agree to use DJB's Curve25519... +1
Re: How to securely encrypt identical files to identical ciphertext?
From: Roberto Spadim robe...@spadim.com.br
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
