I've met a similar problem as Sami Farin described in the following ticket:
https://rt.openssl.org/Ticket/Display.html?id=1608
SSL_get_error reports SSL_ERROR_SSL and I get errno 11 (i.e. EAGAIN) after
calling SSL_read.
And I have OpenSSL version 1.0.1h.
How can I avoid this problem?
I am looki
This transaction appears to have no content
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4652
Please log in as guest with password guest if prompted
bing3SJLjbBgp.bin
Description: Binary data
binVMhkjd8tES.bin
Description: Binary data
--
openssl-dev mailing list
To unsubscrib
This transaction appears to have no content
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4652
Please log in as guest with password guest if prompted
bint4MGWkFJBi.bin
Description: Binary data
binjrnzFcAqj2.bin
Description: Binary data
--
openssl-dev mailing list
To unsubscrib
Very helpful, thanks! So that's not an actual issue.
Which do you think is more pressing from your project's perspective:
removing BUF_MEM dependency on int, or streaming decode for smime? While
certainly non-trivial, the latter is certainly more isolated for a
newcomer. On the other hand, the
Andy Polyakov wrote:
> It appears to me that with multiplication, squaring, subtraction,
> negation, halving *preserving* property of being fully reduced (i.e. if
> inputs are fully reduced, then output is too), we only have to watch out
> for mul_by_[23], i.e. ensure that their outputs are fully
Andy Polyakov wrote:
>>if (P256_LIMBS == 8) {
>> res |= a[4] ^ ONE[4];
>> res |= a[5] ^ ONE[5];
>> res |= a[6] ^ ONE[6];
>> +res |= a[7] ^ ONE[7];
>>}
>
> It's not actually a coincidence that it ends with a[6]. If you have
> close look at ecp_nistz256_is_affine_G, you'll
On Thu, Aug 18, 2016 at 04:24:56PM +0200, Andy Polyakov wrote:
> >> I think you are assuming that ret is in the range [0, 2P), so that if
> >> you subtract P, the result would be in the range [0, P). That is the
> >> case in normal Montgomery multiplication, where the inputs are in the
> >> range [
On Thu Aug 18 14:01:03 2016, bmor...@mortoninsights.com wrote:
> Ok, so this might be a separate issue. Please let me know what you think
> and I can file. The issue is pretty much irrelevant since you can't
> decrypt anything over 1.5G.
>
> Try this:
>
> bmorton@athens:~$ dd if=/dev/urandom of=sam
>> I think you are assuming that ret is in the range [0, 2P), so that if
>> you subtract P, the result would be in the range [0, P). That is the
>> case in normal Montgomery multiplication, where the inputs are in the
>> range [0, P). But, my understanding is that if the inputs are in the
>> range
Ok, so this might be a separate issue. Please let me know what you think
and I can file. The issue is pretty much irrelevant since you can't
decrypt anything over 1.5G.
Try this:
bmorton@athens:~$ dd if=/dev/urandom of=sample.txt bs=512K count=6144
6144+0 records in
6144+0 records out
322122547
On Thu Aug 18 00:40:21 2016, bmor...@mortoninsights.com wrote:
>
> Regardless of input size (2GB or 30GB) to the smime application, the
> resulting encrypted file is only 1.9GB on disk. Unless smime format
> has
> some very serious compression, it looks like it is silently truncating
> input. A 32
need more content here. or post to openssl-users if you are just asking a
question.
https://mta.openssl.org for list information.
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4652
Please log in as guest with password guest if prompted
--
openssl-dev mailing list
To unsubscribe:
This transaction appears to have no content
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4652
Please log in as guest with password guest if prompted
binfRsIEa37iM.bin
Description: Binary data
bin6mX0uBCo7K.bin
Description: Binary data
--
openssl-dev mailing list
To unsubscrib
> Please see the attached program and consider the following change:
>
> ```
>if (P256_LIMBS == 8) {
> res |= a[4] ^ ONE[4];
> res |= a[5] ^ ONE[5];
> res |= a[6] ^ ONE[6];
> +res |= a[7] ^ ONE[7];
>}
It's not actually a coincidence that it ends with a[6]. If you have
c
14 matches
Mail list logo
