On Wed, 2016-10-05 at 20:46 +0100, Matt Caswell wrote:
>
> Or even 1.1.1! Why don't you pull this together into a github PR?
https://github.com/openssl/openssl/pull/1666
Not complete, but good enough for you to heckle at the approach, and
it'll be a whole lot simpler for someone with more clue t
On 05/10/16 22:51, David Woodhouse wrote:
> On Wed, 2016-10-05 at 21:29 +0100, Matt Caswell wrote:
>> Hwell its not constant even by cipher. It depends on the
>> transport (IPv6 has a bigger overhead than IPv4).
>
> That is included in d1->link_mtu (DTLS_set_link_mtu()) but is not
> incl
On Wed, 2016-10-05 at 21:29 +0100, Matt Caswell wrote:
> Hwell its not constant even by cipher. It depends on the
> transport (IPv6 has a bigger overhead than IPv4).
That is included in d1->link_mtu (DTLS_set_link_mtu()) but is not
included in d1->mtu (SSL_set_mtu()).
Even when we let DTL
On Wed, 2016-10-05 at 21:31 +0100, Matt Caswell wrote:
>
>
> On 05/10/16 15:37, David Woodhouse wrote:
> > DTLS_set_link_mtu(vpninfo->dtls_ssl, mtu);
> >
> > /* We already set the link MTU, but hopefully by the time we
> > * finish it, this function will be better at working o
On 05/10/16 15:37, David Woodhouse wrote:
> DTLS_set_link_mtu(vpninfo->dtls_ssl, mtu);
>
> /* We already set the link MTU, but hopefully by the time we
>* finish it, this function will be better at working out the
>* actual tunnel MTU than OpenSSL is. So do that too..
On 05/10/16 20:59, David Woodhouse wrote:
>
>>
>>
>> On 05/10/16 15:37, David Woodhouse wrote:
>>> On Wed, 2016-10-05 at 14:40 +0100, David Woodhouse wrote:
How's this for a start...
>>>
>>> Now I think I have it right for CCM too, although having to use
>>> strstr() for that makes me *very
>
>
> On 05/10/16 15:37, David Woodhouse wrote:
>> On Wed, 2016-10-05 at 14:40 +0100, David Woodhouse wrote:
>>> How's this for a start...
>>
>> Now I think I have it right for CCM too, although having to use
>> strstr() for that makes me *very* sad. Next up, Chacha20-Poly1305...
>> and then maybe
On 05/10/16 15:37, David Woodhouse wrote:
> On Wed, 2016-10-05 at 14:40 +0100, David Woodhouse wrote:
>> How's this for a start...
>
> Now I think I have it right for CCM too, although having to use
> strstr() for that makes me *very* sad. Next up, Chacha20-Poly1305...
> and then maybe I can sto
One more reference: https://tools.ietf.org/html/rfc4648#section-3.3
describes the considerations for 'non-base64 characters'.
Short form: MIME requires that they be ignored. 7468 says SHOULD.
4648 says 'reject, unless the referencing spec says otherwise' (which
7468 does.)
I wrote previously that
On Wed, 2016-10-05 at 14:40 +0100, David Woodhouse wrote:
> How's this for a start...
Now I think I have it right for CCM too, although having to use
strstr() for that makes me *very* sad. Next up, Chacha20-Poly1305...
and then maybe I can stop worrying about new modes and ciphersuites
because tho
On 10/05/2016 07:56 AM, Richard Levitte via RT wrote:
> To be noted, there's more in section 2:
>
>Most extant parsers ignore blanks at the ends of lines; blanks at the
>beginnings of lines or in the middle of the base64-encoded data are
>far less compatible. These observations are cod
On 05-Oct-16 08:56, Richard Levitte via RT wrote:
> To be noted, there's more in section 2:
>
>Most extant parsers ignore blanks at the ends of lines; blanks at the
>beginnings of lines or in the middle of the base64-encoded data are
>far less compatible. These observations are codifie
Yes, Steve, you're right!
Thank you.
I'm sorry for imprecise wording.
Sergey.
2016-10-05 16:24 GMT+05:00 Stephen Henson via RT :
> On Wed Oct 05 07:05:06 2016, sgbrazhni...@gmail.com wrote:
> > Hi, guys.
> >
> > Just figured out that files encrypted with OpenSSL 1.1.0-stable can not
> be
> > de
On Wed, 2016-10-05 at 10:04 +0100, Matt Caswell wrote:
>
> > For example for AES-128-GCM-SHA256 we'd start with 1500 and subtract:
> > - 20 bytes for a Legacy IP header.
> > - 8 bytes for UDP header.
> > - 13 bytes for DTLS header
> > - 16 bytes for the hash
> > - 8 bytes for nonce
> >
> > .
Confirmed - thanks for the reply!
From: Rich Salz via RT
Sent: 05 October 2016 08:09:49
To: Llewelyn Thomas
Subject: [openssl.org #4696] Resolved: BUG: openssl1.0.2j Solaris-Sparc :
../util/shlib_wrap.sh ./bad_dtls_test - core dump
According to our records, your
To be noted, there's more in section 2:
Most extant parsers ignore blanks at the ends of lines; blanks at the
beginnings of lines or in the middle of the base64-encoded data are
far less compatible. These observations are codified in Figure 1.
The most lax parser implementations are n
On 05-Oct-16 07:52, Salz, Rich via RT wrote:
> Well, it is a SHOULD not a MUST. But point taken it could be (much) better :)
>
>
It's an important SHOULD. Whitespace introduction happens in the wild.
This is the quote from the OpenXPKI folks:
> I just saw this today at a customer install that a
Well, it is a SHOULD not a MUST. But point taken it could be (much) better :)
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4698
Please log in as guest with password guest if prompted
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-d
PEM consists of base64 inside a header and trailer line.
OpenSSL crashes with embedded newlines. This was mentioned to me by the
OpenXPKI project.
See RFC 7468 section 2:
Data before the encapsulation boundaries are
permitted, and parsers MUST NOT malfunction when processing such
data.
On Wed Oct 05 07:05:06 2016, sgbrazhni...@gmail.com wrote:
> Hi, guys.
>
> Just figured out that files encrypted with OpenSSL 1.1.0-stable can not be
> decrypted with previous releases and vice versa.
> Tested aes256, cast5-cfb, camellia128 on 1.1.0-stable, 1.0.2-stable and
> 0.9.8(cast5-cfb only)
On Wed, 2016-10-05 at 09:08 +, Salz, Rich via RT wrote:
> I think you are reading too much into Viktor's words. From my
> perspective he was proposing a work-around, nothing more.
OK, that makes sense.
> Yeah, what we did is sub-optimal. Not the first time, won't be the
> last :)
:)
--
I think you are reading too much into Viktor's words. From my perspective he
was proposing a work-around, nothing more.
Yeah, what we did is sub-optimal. Not the first time, won't be the last :)
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4697
Please log in as guest with pass
On Wed, 2016-10-05 at 08:03 +, Salz, Rich wrote:
>
> > And the *only* justification for the fact that bug continues to exist — and
> > in
> > fact we introduced a *new* bug in OpenSSL 1.1 instead of fixing it — is for
> > backward compatibility with older releases.
> >
> > So how can we be s
On 05/10/16 00:39, David Woodhouse wrote:
> I have the link MTU (typically 1500 bytes), and a DTLS session is
> established.
>
> I call DTLS_set_link_mtu() to set the link MTU.
>
> I need to know the DTLS data MTU — the maximum payload size, which
> depends on the cipher in use.
>
> For exampl
> And the *only* justification for the fact that bug continues to exist — and in
> fact we introduced a *new* bug in OpenSSL 1.1 instead of fixing it — is for
> backward compatibility with older releases.
>
> So how can we be so sanguine about the above failure report?
Because backward compatib
On Wed, 2016-10-05 at 07:05 +, Sergey G Brazhnikov via RT wrote:
>
> Just figured out that files encrypted with OpenSSL 1.1.0-stable can not be
> decrypted with previous releases and vice versa.
> Tested aes256, cast5-cfb, camellia128 on 1.1.0-stable, 1.0.2-stable and
> 0.9.8(cast5-cfb only)
On Wed, 2016-10-05 at 07:05 +, Sergey G Brazhnikov via RT wrote:
>
> Just figured out that files encrypted with OpenSSL 1.1.0-stable can not be
> decrypted with previous releases and vice versa.
> Tested aes256, cast5-cfb, camellia128 on 1.1.0-stable, 1.0.2-stable and
> 0.9.8(cast5-cfb only)
On Wed, 2016-10-05 at 07:17 +, Viktor Dukhovni wrote:
> On Wed, Oct 05, 2016 at 07:05:06AM +, Sergey G Brazhnikov via RT wrote:
>
> >
> > Just figured out that files encrypted with OpenSSL 1.1.0-stable can not be
> > decrypted with previous releases and vice versa.
> > Tested aes256, cast
On Wed, Oct 05, 2016 at 07:05:06AM +, Sergey G Brazhnikov via RT wrote:
> Just figured out that files encrypted with OpenSSL 1.1.0-stable can not be
> decrypted with previous releases and vice versa.
> Tested aes256, cast5-cfb, camellia128 on 1.1.0-stable, 1.0.2-stable and
> 0.9.8(cast5-cfb on
Hi, guys.
Just figured out that files encrypted with OpenSSL 1.1.0-stable can not be
decrypted with previous releases and vice versa.
Tested aes256, cast5-cfb, camellia128 on 1.1.0-stable, 1.0.2-stable and
0.9.8(cast5-cfb only)
All built without errors, passed all tests.
Configuration VC-WIN32, o
30 matches
Mail list logo