On Fri, Aug 15, 2008 at 8:15 PM, Larry Bugbee <[EMAIL PROTECTED]> wrote:
>> Is it possible to define other (SHA512, SHA256, etc)
>> SignatureAlgorithms for use?
>
> Yes, if you use 0.9.9-dev. Take a look at ftp.openssl.org. (Cert sigs
> using 0.9.8 always used SHA-1 regardless of how I attempted
Mike,
I have installed openssl on 64 bit OS. I believe 64-bit libraries
produced by default if we try to build OpenSSL on a 64-bit platform.
I would still like to verify whether the installed openssl is 32, or
64 bit . Can you please let me know the necessary commands to verify
it ?
On 8/15/08,
Is it possible to define other (SHA512, SHA256, etc)
SignatureAlgorithms for use?
Yes, if you use 0.9.9-dev. Take a look at ftp.openssl.org. (Cert
sigs using 0.9.8 always used SHA-1 regardless of how I attempted to
specify SHA-256 etc.)
Well, the question becomes: Which government are you trying to work
around the restrictions of?
OpenSSL is open-source. In the United States, while it may fall under
the export class EI on the CCR, it also falls under export exemption
TSU (see http://www.access.gpo.gov/bis/ear/txt/740.txt (sectio
On Fri August 15 2008 12:51, Andrey Petrashenko wrote:
> Hello.
> I have a task to exchange data between an web-browser and my openssl-based
> SSL server on local system. As for a SSL-server I should provide SSL
> certificate but I can't because the name "localhost" is not trusted by
> default and
Hello.
I have a task to exchange data between an web-browser and my openssl-based
SSL server on local system. As for a SSL-server I should provide SSL
certificate but I can't because the name "localhost" is not trusted by
default and it's impossible to get authorized certificate. It's not good to
w
I suspect your 'actual government reps' are actually either misinformed
or willfully misleading you (or perhaps incompetent).
Consult a lawyer who practices in this area. I am unaware of any
restrictions, except to countries labeled as supporters of terrorism.
Best regards.
Fred Picher wro
Fred Picher wrote:
> Hello,
>
> Thanks for your reply.
>
>
>> If this is not sufficient you may check out ssl/sslv3.c etc and
>> actually remove the ciphers you don't want to support in your
>> libssl from the registration tables.
>>
>
> As a test, I've commented out every cipher definiti
Hello,
Thanks for your reply.
> If this is not sufficient you may check out ssl/sslv3.c etc and
> actually remove the ciphers you don't want to support in your
> libssl from the registration tables.
As a test, I've commented out every cipher definition in
ssl/s3_lib.c, like this example:
The
On Thu August 14 2008 23:05, Rafiqul Ahsan wrote:
> Hi David,
>
> I believe 2048 could not be the issue (as you said because I am using
> 64 bit OS),
>
Which will probably run either 32bit or 64bit userland code.
Next question: Are you running 64bit openSSL?
(You could be running 32bit openSSL a
On Thu, Aug 14, 2008 at 3:30 PM, Ambarish Mitra
<[EMAIL PROTECTED]> wrote:
>
> AM: Either the corruption happens in this call, or in the preceeding
> EVP_CIPHER_CTX_init call.
>
Since the assert() already fails before the init_ex call, it looks
like my guess is probably c
Cheers!
Thanks for the info, I managed to fix the problem by upgrading via the
source code to openssl-0.9.7d.
David
On Fri, 2008-08-08 at 08:30 -0500, Michael S. Zick wrote:
> On Fri August 8 2008 05:10, Ger Hobbelt wrote:
> >
>
> It may not be the number itself, but the file indexing;
>
>
>
12 matches
Mail list logo