Re: Combining MD5 and SHA-1 to reduce collision probability
Thank you all for your valuable answers. On 22/04/2011 00:33, Dave Thompson wrote: *Accidental* (birthday) collision is about 264 for MD5 and about 280 for SHA-1. SHA-256 should be much stronger, would this be sufficient for your needs? Or SHA-512? That's simpler and probably at least as good as a hybrid. It's still not an absolute guarantee, though. To be honest, I've no particular need, I was just auditing someone else realization... -- Luc Perthuis, Team Leader, Backup and Restore Technologies luc.perth...@atempo.com T +33 (0)2 97 68 40 26 | M +33 (0)6 89 16 96 37 http://www.atempo.com Atempo | Data Management, Simplified. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Combining MD5 and SHA-1 to reduce collision probability
Hi all, I'm specially interested on finding a way to uniquely identify rather small data chunks (less than or equal to 128*1024 bytes in size) without using a byte per byte compare. Is there any theoretical proof for a good selection of 2 HASH (computing the results of two different algorithms on the same data) that would annihilate the collision risk ? Unfortunately, I'd guess that the answer could be no, but among the experts on this list, I hope to catch a solid proof, not only a guess. NB: I've mentioned MD5 and SHA-1 in the subject, as they are the most used nowadays, but if this association doesn't fit the need whereas another does, that would be interesting anyway ;-) -- Luc Perthuis, Team Leader, Backup and Restore Technologies luc.perth...@atempo.com __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: AES in counter mode no support in openssl
sagar gupta wrote: hi all, I have been working on openssl 1.0.0 for support on AES encryption method in counter mode. I was wondering wheter there is any support for AES in counter mode in Openssl. Please tell me where to find the corresponding source for the AES counter mode if there is support for the that in openssl. If there is no support for AES counter mode i wanted to know why the support is not yet added to the openssl library. Any answers in this regard will be of great help. Thanks in advance Regards If I remember well, there was a thread on the same subject (probably last year, or a while before) to explain why this is not implemented. I'm pretty sure you can find your answer in the archives of this mailing list. -- Luc Perthuis, Team Leader, Backup and Restore Technologies luc.perth...@atempo.com T +33 (0)2 97 68 40 26 | M +33 (0)6 89 16 96 37 http://www.atempo.com Atempo | Data Management, Simplified. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] Re: Which datatype for passphrase?
Steffen DETTMER wrote: (...) BTW, for passphrases to be entered by humans (without binary zeros inside) I think C-strings could be suited, the data type for some entry function could be `char *const passphrase' and for some function that uses it maybe `const char *const passphrase'. Is that right? The interest I have in this thread is about encoding. Does this char * contains US-ASCII or LATIN1 or ANSI or UTF-8 or whatever ? In other words are passphrases in the scope of I18N concern ? If yes, how ? If no, why ? oki, Steffen -- About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] -- alea+ Luc __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Library loading issue on multi processor Windows 2003
Mark wrote: Luc, Have you implemented the CRYPTO locking callbacks? Mark __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] Well, my sample code is such simple that i did not think to implement them. Nevertheless, it works really fine on ANY platform it has been tested, BUT under quadri Xeon Windows 2003. As a matter of fact, there is NO multithreading involved in my test. ONLY multi processing. As far as i understood, the crypto locking callbacks are usefull only when multi threading is involved. Then, do you really think the crypto locking callbacks can do anything for me ? Well, i'll try to extract mttest.c corresponding code to do some more tests ... -- alea+ Luc begin:vcard fn:Luc Perthuis n:Perthuis;Luc org:Atempo S.A.;Engineering adr:;;PIBS;VANNES;;56000;FRANCE email;internet:[EMAIL PROTECTED] title:Core Technologies Group Manager tel;work:02 97 68 40 26 tel;fax:02 97 68 40 25 tel;cell:06 89 16 96 37 note;quoted-printable:Enabling Information Lifecycle Strategies=0D=0A= x-mozilla-html:TRUE url:http://www.atempo.com version:2.1 end:vcard
Re: Library loading issue on multi processor Windows 2003
Marek Marcola wrote: Hello, Mark wrote: I'm not an expert in OpenSSL but AFAIK OpenSSL uses threads internally and the locking callbacks are necessary to synchronise its internal data. Perhaps someone else can clarify this? OpenSSL does not use threads internally and if you don't use threads too in your program then there is no need to implement static locking callback (for example for daemon working in fork() mode). Best regards, Thanks Marek ! That's what i've just understood closely comparing my small sample and crypto/threads/mttest.c. But, so far, that does not solve nor explain the found issue. Is there anyone up there with an idea of how to close it ? Some tests around compiling openssl libs with some specific flags for VC7 compiler are on the fly. But they will probably take some time to converge (if ever). So any help will be welcome. -- alea+ Luc begin:vcard fn:Luc Perthuis n:Perthuis;Luc org:Atempo S.A.;Engineering adr:;;PIBS;VANNES;;56000;FRANCE email;internet:[EMAIL PROTECTED] title:Core Technologies Group Manager tel;work:02 97 68 40 26 tel;fax:02 97 68 40 25 tel;cell:06 89 16 96 37 note;quoted-printable:Enabling Information Lifecycle Strategies=0D=0A= x-mozilla-html:TRUE url:http://www.atempo.com version:2.1 end:vcard
Re: Library loading issue on multi processor Windows 2003
As a state of art information: one of our customers that had this issue
removed a CPU from his computer, and the issue vanished ! 8-)
Unfortunately, not all of our customers agree to downgrade thier
computers, so, please, if anyone has an advice about how to handle this
issue, it will be welcome !
Luc Perthuis wrote:
Hello!
We've got an issue using openssl (0.9.8a to 0.9.8d) libraries with our
product.
It works fine on any Unix or even on most windows platforms.
But, unfortunately, it crashes if run on a quadri pro Xeon Windows
2003 platform.
There is no evidence that's the only platform to show this issue, but
it actually happens on at least four instances of such a machine.
The stack of the crash often contains RAND_POLL but doesn't seem to
be reliable.
We could reproduce the same issue with the very simple code attached
here.
It crashes only if a bunch of executables are launched in a very short
time.
Sounds like a real time issue at loading time ... quite strange.
Well loading time is an hypothesis based on the stack: most of the
time it appears to happen before entering main.
We know that windows loads and initialises the DLL modules before
calling main ... hence our hypothesis
A command line like the following one may be usefull to reproduce the
issue (it creates 200 wrnd instances):
for %i in (0 1 2 3 4 5 6 7 8 9 a b c d e f g h i j) do start /min
/high wrnd.exe start /min /high wrnd.exe start /min /high wrnd.exe
start /min /high wrnd.exe start /min /high wrnd.exe start /min
/high wrnd.exe start /min /high wrnd.exe start /min /high wrnd.exe
start /min /high wrnd.exe start /min /high wrnd.exe
wrnd.exe being built from the attached sample source code
Any hint or help around such an issue will be really welcome.
In case it could matter, here are the command lines used to build the
executable:
c:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\Bin\cl.exe
-IC:\3rdparty\openssl-0.9.8a\inc32 -Ic:\Program Files\Microsoft
Visual Studio .NET 2003\Vc7\Include /D WIN32 /GR /Ob1 /Oi /Ot /Gs
/Gm- /Gy /D NDEBUG /MD /Zi /GL /wd4786 /GB /Oy /TC /c /W3 /EHsc
/Zm1000 -c -o test.obj test.c
c:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\Bin\link.exe
/LTCG:status /nologo /nodefaultlib /out:wrnd.exe test.obj
C:\openssl\lib\libeay32.lib C:\openssl\lib\ssleay32.lib
c:\Program Files\Microsoft Visual Studio .NET
2003\Vc7\lib\msvcrt.lib c:\Program Files\Microsoft
SDK\lib\kernel32.lib c:\Program Files\Microsoft Visual Studio .NET
2003\Vc7\lib\OLDNAMES.lib
#include stdio.h
#include time.h
#include openssl/err.h
#include openssl/ssl.h
#include openssl/rand.h
#ifdef WIN32
#include windows.h
#define my_sleep(n) Sleep(1000*(n))
#else
#define my_sleep(n) sleep(n)
#endif
int main(int argc)
{
register int i, j;
int retcode = 0;
time_t start, end;
char buffer [2000];
unsigned char data [512];
const char *file = NULL;
const char rng_seed [] = string to make the random number \
generator think it has entropy ;);
time(start);
if (argc != 1) {
#ifdef WIN32
DebugBreak();
#else
while (argc != 1) {
sleep(1);
}
#endif
}
ERR_load_crypto_strings ();
SSL_load_error_strings ();
file = RAND_file_name (buffer, sizeof (buffer));
if (file != NULL) {
printf(Rand file = %s\n, file);
retcode = RAND_load_file (file, -1);
}
#ifdef WIN32
RAND_screen ();
#endif
if (file == NULL || !retcode) {
if (RAND_status () == 0) {
RAND_seed (rng_seed, sizeof (rng_seed) - 1);
}
}
printf(RAND_status = %d\n, RAND_status());
j=123;
for (i=0; i41; i++) {
my_sleep(1+(data[j]%13));
if (!RAND_bytes(data, 512)) {
printf(Rand generation stopped at step %d\n, i);
ERR_print_errors_fp(stdout);
break;
}
j=data[j];
}
if (file != NULL) {
retcode = RAND_write_file (file);
}
RAND_cleanup ();
ERR_print_errors_fp(stdout);
EVP_cleanup ();
CRYPTO_cleanup_all_ex_data ();
ERR_remove_state (0);
ERR_free_strings ();
time(end);
printf(time ellapsed: %d seconds\n, (int)(end-start));
return retcode;
}
--
alea+
Luc
begin:vcard
fn:Luc Perthuis
n:Perthuis;Luc
org:Atempo S.A.;Engineering
adr:;;PIBS;VANNES;;56000;FRANCE
email;internet:[EMAIL PROTECTED]
title:Core Technologies Group Manager
tel;work:02 97 68 40 26
tel;fax:02 97 68 40 25
tel;cell:06 89 16 96 37
note;quoted-printable:Enabling Information Lifecycle Strategies=0D=0A=
x-mozilla-html:TRUE
url:http://www.atempo.com
version:2.1
end:vcard
Library loading issue on multi processor Windows 2003
Hello!
We've got an issue using openssl (0.9.8a to 0.9.8d) libraries with our
product.
It works fine on any Unix or even on most windows platforms.
But, unfortunately, it crashes if run on a quadri pro Xeon Windows 2003
platform.
There is no evidence that's the only platform to show this issue, but it
actually happens on at least four instances of such a machine.
The stack of the crash often contains RAND_POLL but doesn't seem to be
reliable.
We could reproduce the same issue with the very simple code attached here.
It crashes only if a bunch of executables are launched in a very short time.
Sounds like a real time issue at loading time ... quite strange.
Well loading time is an hypothesis based on the stack: most of the
time it appears to happen before entering main.
We know that windows loads and initialises the DLL modules before
calling main ... hence our hypothesis
A command line like the following one may be usefull to reproduce the
issue (it creates 200 wrnd instances):
for %i in (0 1 2 3 4 5 6 7 8 9 a b c d e f g h i j) do start /min /high
wrnd.exe start /min /high wrnd.exe start /min /high wrnd.exe start
/min /high wrnd.exe start /min /high wrnd.exe start /min /high
wrnd.exe start /min /high wrnd.exe start /min /high wrnd.exe start
/min /high wrnd.exe start /min /high wrnd.exe
wrnd.exe being built from the attached sample source code
Any hint or help around such an issue will be really welcome.
In case it could matter, here are the command lines used to build the
executable:
c:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\Bin\cl.exe
-IC:\3rdparty\openssl-0.9.8a\inc32 -Ic:\Program Files\Microsoft Visual
Studio .NET 2003\Vc7\Include /D WIN32 /GR /Ob1 /Oi /Ot /Gs /Gm- /Gy /D
NDEBUG /MD /Zi /GL /wd4786 /GB /Oy /TC /c /W3 /EHsc /Zm1000 -c -o
test.obj test.c
c:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\Bin\link.exe
/LTCG:status /nologo /nodefaultlib /out:wrnd.exe test.obj
C:\openssl\lib\libeay32.lib C:\openssl\lib\ssleay32.lib c:\Program
Files\Microsoft Visual Studio .NET 2003\Vc7\lib\msvcrt.lib c:\Program
Files\Microsoft SDK\lib\kernel32.lib c:\Program Files\Microsoft Visual
Studio .NET 2003\Vc7\lib\OLDNAMES.lib
--
alea+
Luc
#include stdio.h
#include time.h
#include openssl/err.h
#include openssl/ssl.h
#include openssl/rand.h
#ifdef WIN32
#include windows.h
#define my_sleep(n) Sleep(1000*(n))
#else
#define my_sleep(n) sleep(n)
#endif
int main(int argc)
{
register int i, j;
int retcode = 0;
time_t start, end;
char buffer [2000];
unsigned char data [512];
const char *file = NULL;
const char rng_seed [] = string to make the random number \
generator think it has entropy ;);
time(start);
if (argc != 1) {
#ifdef WIN32
DebugBreak();
#else
while (argc != 1) {
sleep(1);
}
#endif
}
ERR_load_crypto_strings ();
SSL_load_error_strings ();
file = RAND_file_name (buffer, sizeof (buffer));
if (file != NULL) {
printf(Rand file = %s\n, file);
retcode = RAND_load_file (file, -1);
}
#ifdef WIN32
RAND_screen ();
#endif
if (file == NULL || !retcode) {
if (RAND_status () == 0) {
RAND_seed (rng_seed, sizeof (rng_seed) - 1);
}
}
printf(RAND_status = %d\n, RAND_status());
j=123;
for (i=0; i41; i++) {
my_sleep(1+(data[j]%13));
if (!RAND_bytes(data, 512)) {
printf(Rand generation stopped at step %d\n, i);
ERR_print_errors_fp(stdout);
break;
}
j=data[j];
}
if (file != NULL) {
retcode = RAND_write_file (file);
}
RAND_cleanup ();
ERR_print_errors_fp(stdout);
EVP_cleanup ();
CRYPTO_cleanup_all_ex_data ();
ERR_remove_state (0);
ERR_free_strings ();
time(end);
printf(time ellapsed: %d seconds\n, (int)(end-start));
return retcode;
}
begin:vcard
fn:Luc Perthuis
n:Perthuis;Luc
org:Atempo S.A.;Engineering
adr:;;PIBS;VANNES;;56000;FRANCE
email;internet:[EMAIL PROTECTED]
title:Core Technologies Group Manager
tel;work:02 97 68 40 26
tel;fax:02 97 68 40 25
tel;cell:06 89 16 96 37
note;quoted-printable:Enabling Information Lifecycle Strategies=0D=0A=
x-mozilla-html:TRUE
url:http://www.atempo.com
version:2.1
end:vcard
Re: AES192 in CTR mode - crypted result looks like ECB
Luc Perthuis wrote: Marty Lamb wrote: How are you deriving CTR from OFB? Well, i imagine the issue is somewhere around there. Unfortunately, i can't figure out where. When i launch './crypt -phrase AES-192-OFB -in small.txt -out small.ssl', i get for exemple: 97 occurrences of 43 f9 e5 0e cc b2 and 98 of 37 8d 91 7a b8 c6 But hopefully openssl enc -aes-192-ofb -in 5a.txt -out enc.ofb -md sha1 -k AES-192-OFB gives a very better quality output: not even a single 5 bytes sequence can be find more than once. 5a.txt is the BIG version of small.txt We're still working on fiding where's the problem, but if anyone (who has kept the post with the source file) can point out what's wrong, it would really help. Even, just an advice like Hey, CTR should be derived from CBC and not OFB. Well, I know the source file is two large ... even though I've tried to make it as small as possible without breaking the whole stuff. Thus i can understand no one has enough time to spend on it :'( -- alea+ Luc begin:vcard fn:Luc Perthuis n:Perthuis;Luc org:Atempo S.A.;Engineering adr:;;PIBS;VANNES;;56000;FRANCE email;internet:[EMAIL PROTECTED] title:Core Technologies Group Manager tel;work:02 97 68 40 26 tel;fax:02 97 68 40 25 tel;cell:06 89 16 96 37 note;quoted-printable:Enabling Information Lifecycle Strategies=0D=0A= x-mozilla-html:TRUE url:http://www.atempo.com version:2.1 end:vcard
Re: Decryption fails
Kaushalye Kapuruge wrote: Hi, Im trying to encrypt/decrypt a string using openssl. The program works fine for encryption but fails(not always) for decryption. This happens in EVP_CipherFinal_ex() call. I'm a bit confused with this random behavior. I've attached the code. Can anybody point me out what I'm doing wrong here? Thanks, Kaushalye (...) /* Bogus key and IV: we'd normally set these from * another source. */ unsigned char key[] = 0123456789; unsigned char iv[] = 12345671; As pointed out in another thread, key and IV should both have the correct size for the intended algorithm. Thus, key and/or IV read by EVP_CipherInit_ex may well be quite undetermined, which is a good reason for a random result. You probably should use some PKSC#5 procedure, or at least something like EVP_BytesToKey() to derive a good Key/IV pair from a passphrase/salt pair. Anyway, I'm not sure it's a good idea to force the key length using EVP_CIPHER_CTX_set_key_length(). Here, i'd rather let someone else give the correct answer. -- alea+ Luc begin:vcard fn:Luc Perthuis n:Perthuis;Luc org:Atempo S.A.;Engineering adr:;;PIBS;VANNES;;56000;FRANCE email;internet:[EMAIL PROTECTED] title:Core Technologies Group Manager tel;work:02 97 68 40 26 tel;fax:02 97 68 40 25 tel;cell:06 89 16 96 37 note;quoted-printable:Enabling Information Lifecycle Strategies=0D=0A= x-mozilla-html:TRUE url:http://www.atempo.com version:2.1 end:vcard
Re: AES192 in CTR mode - crypted result looks like ECB
Marty Lamb wrote:
Luc Perthuis wrote:
Hello,
Any advice on this ECB like behaviour of CTR will be highly appreciated.
We are currently integrating openssl in our application.
One of the goals is to use symetric encription on streams of data to
keep them encrypted on a storage device (1).
As far as we are concerned, CTR mode seems to be a good choice for
this goal.
The idea is to use (according to some parameters) either des, 3des,
aes, blowfish or cast5.
Another parameter also permits to chose one hash algorithm.
As openssl does not support CTR mode, it is derived from OFB (as in
EVP_get_cipherbyname(SN_aes_192_ofb128) for instance).
How are you deriving CTR from OFB?
Well, i imagine the issue is somewhere around there.
Unfortunately, i can't figure out where.
When i launch './crypt -phrase AES-192-OFB -in small.txt -out
small.ssl', i get for exemple:
97 occurrences of 43 f9 e5 0e cc b2 and 98 of 37 8d 91 7a b8 c6
You can try it as same pass phrase should give same output.
'crypt' being compiled from sample code joint here
small.txt being a 150 line text file (see construction at end of mail),
Note that decryption is same process as encryption, 'cause we use CTR
(or OFB), and it works fine.
But those redundancies look like saying Hey, guy, it's not as secure as
you hope it should be.
You may want to take a look at void AES_ctr128_encrypt() in
crypto/aes/aes_ctr.c (at least, that's where it is in my 0.9.7j-dev
source). I've used it to both encrypt and decrypt successfully. On
our hardware, OpenSSL's CTR performance is *excellent* compared with
other AES modes. Start with num=0 and a bzero'ed ecount_buf and you
should be good to go.
Indeed, in the past it was something like that, apart that we did not
use openssl at all ...
Sorry, i've been quite long extracting this sample from our real code ...
-- source file description --
alternating 10 lines of 5 and 10 lines of A ...
$ grep -c
small.txt
80
$ grep -c
small.txt
70
$ wc 5a.txt
16 16 1168 5a.txt
--
alea+
Luc
/* extracted sample for FED (File Encrypt Decrypt) */
#include stdio.h
#include stdlib.h
#include openssl/evp.h
#include openssl/crypto.h
#include openssl/err.h
#include openssl/rand.h
#include openssl/ssl.h
#define FILE_NAME_MAX_SIZE 256
#define BUFF_MAX_SIZE 1024
#define MAXBLOCKSIZE 128
#define SESSION_IV_BLOCK_SIZE 5
#define SESSION_IV_INNER_SIZE 2
#define CONST64(n) n ## ULL
enum FED_State_enum {
FED_State_Not_Set = 0,
FED_State_Init,
FED_State_In_Use,
FED_State_Closed,
};
typedef enum FED_State_enum FED_State_enum;
typedef struct {
unsigned char ctr_iv [MAXBLOCKSIZE]; /* the IV */
unsigned long long block_number; /* current block number (0..2^36) */
} FED_crypto;
struct FED_Context {
FED_State_enum FED_State; /* Current state flag */
unsigned current_session_no;
unsigned session_set;
const char *context_password;
FED_crypto crypto;
EVP_CIPHER_CTX *ossl_cipher_ctx;
};
typedef struct FED_Context FED_Context;
/* OpenSSL Random initialization: some seeding */
static int sec_rand_init (void)
{
char buffer [200];
const char *file = NULL;
const char rng_seed [] =
=0+The |1*quick/ ^2!brown \3(fOx #4)jUmps, '5[ovER ~6}tHe _7]lazy? @8{dOg
\\9%`$-;
#ifdef __WIN32__
RAND_screen ();
#endif
file = RAND_file_name (buffer, sizeof (buffer));
if (file == NULL || !RAND_load_file (file, -1)) {
if (RAND_status () == 0) {
RAND_seed (rng_seed, sizeof (rng_seed) - 1);
if (RAND_status () == 0) {
return -1;
}
return 0;
}
}
return 0;
}
/* Tina Security module initalization:
* - OpenSSL crypto locking initialization
* - OpenSSL initalization
*/
static int sec_ossl_lib_init (void)
{
int rc = 0;
/* OpenSSL classic init */
OpenSSL_add_all_algorithms ();
OpenSSL_add_ssl_algorithms ();
ERR_load_crypto_strings ();
SSL_load_error_strings ();
/* OpenSSL random init */
rc = sec_rand_init ();
return rc;
}
/* Tina Security module cleanup:
* - OpenSSL crypto locking cleanup
* - OpenSSL cleanup
*/
static int sec_ossl_lib_cleanup (void)
{
int rc = 0;
/* OpenSSL classic cleanup */
EVP_cleanup ();
/* ENGINE_cleanup (); */
CRYPTO_cleanup_all_ex_data ();
ERR_remove_state (0);
ERR_free_strings ();
/* OpenSSL random cleanup */
RAND_cleanup ();
return rc;
}
/* EVP_CipherInit (): initialmize an EVP_CIPHER in OFB mode as CTR one could be
* obtained with it */
static int ossl_EVP_CipherInit_ctr (EVP_CIPHER_CTX *ctx, const char *name,
const unsigned char *key, int key_len,
const unsigned char *iv, int iv_len)
{
int rc = 0;
const EVP_CIPHER *evp_ciph = NULL;
int blk_len = 0;
int half_blk_len = 0;
unsigned char ctr_iv [EVP_MAX_IV_LENGTH
AES192 in CTR mode - crypted result looks like ECB
Hello, Any advice on this ECB like behaviour of CTR will be highly appreciated. We are currently integrating openssl in our application. One of the goals is to use symetric encription on streams of data to keep them encrypted on a storage device (1). As far as we are concerned, CTR mode seems to be a good choice for this goal. The idea is to use (according to some parameters) either des, 3des, aes, blowfish or cast5. Another parameter also permits to chose one hash algorithm. As openssl does not support CTR mode, it is derived from OFB (as in EVP_get_cipherbyname(SN_aes_192_ofb128) for instance). The symetric key and IV are derived from PRNG data and hash using ossl_PKCS5_PBKDF2_HMAC_PRF(). And part of the IV is used as the counter. Unfortunately, there must be something wrong in the current implementation. As an input test stream, i've used a simple patern file: 10 lines of 72 ASCII characters '5', ended with 'new line' 10 lines of 72 ASCII characters 'A', ended with 'new line' and so on up to a total of 16 lines (see at the end for a somewhat clearer description). Analysing the output stream, at least two paterns of as long as 8 bytes is found many many times. This is the reason why i've written 'ECB' in the subject. In fact, it appears that each patern may be found every 48 bytes (40 are quite random, 8 are the patern). This occurs 14 to 15 times, then it switches to the other patern with somewhat the same scheme and so on. On the other hand, any other 4 bytes patern can hardly be found more than once. We would have hoped that the full output stream looked like it was random data. Is this assumption false? Or on the contrary, can we consider that there is a bug in our implementation? NB: in a previous implementation, we where not using openssl, and the CTR mode was derived from CBC. It did not show this strange behaviour. Should we rely on CBC mode to implement CTR one? Or do you think we have a chance to find the flaw in our CTR-based-on-OFB implementation? And at least a newbie question: which are the real adavantages (and drawbacks) of CTR over OFB? (1) another goal is also to protect some network exchanges with SSL, but that's another story. -- source file description -- $ grep -c 5a.txt 8 $ grep -c 5a.txt 8 $ wc 5a.txt 16 16 1168 5a.txt -- alea+ Luc begin:vcard fn:Luc Perthuis n:Perthuis;Luc org:Atempo S.A.;Engineering adr:;;PIBS;VANNES;;56000;FRANCE email;internet:[EMAIL PROTECTED] title:Core Technologies Group Manager tel;work:02 97 68 40 26 tel;fax:02 97 68 40 25 tel;cell:06 89 16 96 37 note;quoted-printable:Enabling Information Lifecycle Strategies=0D=0A= x-mozilla-html:TRUE url:http://www.atempo.com version:2.1 end:vcard
Private key pass phrase constraints
A simple basic question about usable text in a pass phrase used to protect my private key. Well, it's not really openssl specific, but I imagine that the community here should have an answer. Imagine I'm using softwares unicode aware, and then I'm used to use greek, cyrilic and arabic characters. Thus, I would like to do the same (used those exotic chars) to build a strong pass phrase. Is there a chance that several security aware softwares using my certificate can efficiently and reliably use my private key if I want to protect it with a password containing such out of ASCII 7 bits charcaters ? What are the standards that are used to ensure this compatibility ? Hope that the answer is NOT : please stick to ASCII 7 bits pass phrase ;-) -- Best regards, Luc __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Generating certificate
puneet batura wrote: Hi, I am generating a self signed certificate for my application using rsa but i want to generate the certificate using ecc. This is what i am doing: openssl genrsa -out MilitaryGpsKey.pem 2048 openssl req -new -x509 -key MilitaryGpsKey.pem -out MilitaryGpsCert.pem -days 365 now converting the format so tomcat use it: openssl pkcs12 -export -in MilitaryGpsCert.pem -inkey MilitaryGpsKey.pem -out MilitaryGpsCert.p12 -name tomcat i am using openssl-0.9.8a version. Please tell me how to generate a ecc key I am using the same version : openssl version OpenSSL 0.9.8a 11 Oct 2005 For a list of usable curves, just do : openssl ecparam -list_curves And chose one to pass it to -name parameter as above. openssl ecparam -genkey -text -name c2pnb163v3 ASN1 OID: c2pnb163v3 -BEGIN EC PARAMETERS- BggqhkjOPQMAAw== -END EC PARAMETERS- Loading 'screen' into random state - done -BEGIN EC PRIVATE KEY- (...) [key value] -END EC PRIVATE KEY- Add -out file_name for ease of use ;-) The rest of the procedure remains the same ... Thanks -- Regards, Puneet Batura Open Source Developer -- Regards, Luc begin:vcard fn:Luc Perthuis n:Perthuis;Luc org:Atempo S.A.;Engineering adr:;;PIBS;VANNES;;56000;FRANCE email;internet:[EMAIL PROTECTED] title:Core Technologies Group Manager tel;work:02 97 68 40 26 tel;fax:02 97 68 40 25 tel;cell:06 89 16 96 37 note;quoted-printable:Enabling Information Lifecycle Strategies=0D=0A= x-mozilla-html:TRUE url:http://www.atempo.com version:2.1 end:vcard
