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
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
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
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
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
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
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:
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
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
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
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
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
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
Ø 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
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
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
Ø 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
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
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
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
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
- 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
Ø 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
- 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
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
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
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
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
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
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
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,
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
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
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
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
35 matches
Mail list logo
