Hi Vincent,
A random number is needed to generate the IV for AES-CBC.
Please see top of page 22 of RFC 4346.
Alex
On 10/16/07, v.miethe <[EMAIL PROTECTED]> wrote:
>
> Hi all,
>
> May i'am wrong but:
> In function dtls1_enc() iv-size random bytes will be added to input before
> encryption. (if bl
On Tue, Oct 16, 2007 at 01:54:44AM +0200, Dr. Stephen Henson wrote:
> On Mon, Oct 15, 2007, Kurt Roeckx wrote:
>
> > Hi,
> >
> > The security announcement had this in it:
> > > Recommendation
> > > --
> > >
> > > Either
> > >
> > > a) Upgrade to the latest version of OpenSSL (0.9.8f
Hi all,
May i'am wrong but:
In function dtls1_enc() iv-size random bytes will be added to input before
encryption. (if block cipher... i know.).
In RFC4347 i only found this about encryption.
"DTLS block cipher encryption and decryption are performed exactly as with TLS
1.1.".
And i think in TLS
Darryl Miles wrote:
David Schwartz wrote:
Why are you doing a shutdown(WR) in response to a read()=0 ? Euh!
[...]
Did you miss the "on the local drain file descriptor" part?
No. read()=0 means the shutdown(WR) was performed on the remote end!
Darryl, David Schwartz tries to point out that
David Schwartz wrote:
Nanno Langstraat wrote:
* Our TCP proxy gets read()==0 on the TCP socket.
* In response, our proxy does shutdown(WR) on the local drain file
descriptor (the other side of the proxy).
This propagates the "read()==0" event to the local endpoint
process t
> I want to repeat: it's also OK by me if the documentation *explicitly*
> says somewhere
>
> "SSL can not operate half-duplex like TCP can. SSL_read()==0 means
> the connection is truly dead. You should not do SSL_write() anymore,
> and you can not use the results of SSL_want*() anymo
> Nanno Langstraat wrote:
> >* Remote side completely closes its socket.
> This causes read()=0 and write()=-1/EPIPE on the local side.
>
>
>
> >* Our TCP proxy gets read()==0 on the TCP socket.
> >
> >* In response, our proxy does shutdown(WR) on the local drain file
> > descrip
Nanno Langstraat wrote:
* Remote side completely closes its socket.
This causes read()=0 and write()=-1/EPIPE on the local side.
* Our TCP proxy gets read()==0 on the TCP socket.
* In response, our proxy does shutdown(WR) on the local drain file
descriptor (the other side of
Nanno Langstraat wrote:
That's the very reason Darryl Miles asked me to change the thread title,
if you'll remember.
LOL, but you also have to remove your References: header, but still too
late now. This is still in the same thread, to start a new thread post
a new email (do not use the Repl
David Schwartz wrote:
At that point we get stung because SSL_want_read() erroneously returned
'true' and we therefore registered the SSL-TCP file descriptor for
POLLIN, even though OpenSSL (and only OpenSSL) knows that the SSL-TCP
file descriptor has already returned read()==0.
This is ins
Thor Lancelot Simon wrote:
On Tue, Oct 16, 2007 at 02:41:15AM +0200, Nanno Langstraat wrote:
If you say "The OpenSSL project is becoming comatose, we need
contributors, could you provide a (documentation or code) patch for
this", that's utterly fine.
That's unreasonable, particularly
David Schwartz wrote:
This is insane. Imagine if SSL_want_read and SSL_want_write both returned
false. Then you wouldn't ever notice that the socket had been closed, you
could wait for new inbound data forever, and your proxy would stall.
But end-of-stream is an error condition, so you should b
12 matches
Mail list logo
