Kyle,
Thank you ... I thought I was missing something (actually the
behavior told me what you told me, I just wanted to confirm it was
correct). I won't actually use ECB, it was randomly selected from
the test file ...
A follow-up then ... if I have 37 bytes I would call Update twice and
F
OpenSSL does not store the plaintext size in block protocol usage.
That's an application-layer issue.
ECB mode, by the way, is REALLY discouraged.
Padding doesn't come into play until the second-to-last and last
blocks. You should get 16*(3 blocks of data +1 block for the
EncryptFinal()) == 64
I am trying to do encryption using the "evp" APIs. For testing I am
using "AES-128-ECB" as the cypher. I have no problem encrypting and
decrypting, rather I am having problems with the sizes of the buffers.
My program is largely the same as evp_test.c function "test1" with
the release /opens
Recall that even the 'ca' certificate is ultimately self-signed. So
your question is really about why some self-signed certificates are
more trusted than others.
In some fashion you could ask this question about any typical 'brand
name' store. Why is Store-X trusted more than Store-Y? Sim
guys:
we all know that a ca-signed certificate can provide authentication because the
ca is trustable, by using ca-signed certificate, one is saying "i am somebady
because the ca says so". but it seems that a self-signed certificate _cannot_
provide any authentication at all, because by using s
> Of course, it will be great to have a feature in OpenSSL
> implementation iteslf that will enable SSL session handover / or
> even session sharing between multiple related processes.
Session sharing is pretty hard to do. Handover is not quite as hard. I think
that would be a really great featur
It just occurred to me that the registry key
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\RNG\Seed (type
REG_BINARY) contains the latest seeded value from everything that
CryptoAPI takes into account when generating its random seed.
CryptoAPI permutes it with RC4 to come up with a pseudo-ran
The point of SSL is to provide (possibly) data integrity (detection of
tampering and validation of the source of the data) and secrecy
services /on the wire/. The endpoints have always been known to be
points of concern as they must maintain the keys, both private and
symmetric, in their memory s
>> Since he's talking about a process that forks, there
>> shouldn't be a problem.
>> He just needs to create a shared mapping in the parent. After
>> the 'fork', the address will still be the same.
>
>However if the program forks and calls exec* then this issue could
>arise. The title of the th
I will be out of the office starting 10/13/2006 and will not return until
10/23/2006.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.
David,
> > Agreed. If any object in shared memory contained a pointer to
another
> > object in shared memory this could cause a problem. You would have
to
> > ensure that the shared memory was mapped to the same address in all
> > processes otherwise the pointers would not be valid.
> Since he'
I've generated ECC cert using openssl and was testing with the command:openssl s_client -connect localhost:443.Error was encountered:2028:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:.\ssl\s23_clnt.c:562: Anyone has a idea what the error could mean?I can't be su
12 matches
Mail list logo
