Rob Siemborski wrote:
On Fri, 11 Mar 2005, Marco Colombo wrote:
Ok technically speaking SSL/TLS is not part of SASL. But the two are
related. Maybe I'm biased by the fact that most of the connections I see
are SSL+plaintext. So I was referring to SSL keys actually.
Sure, or, say, kerberos keys.
On Mon, 14 Mar 2005, Marco Colombo wrote:
Now, can you claim conformance to RFC 2831 if you're using /dev/urandom?
Does the fact that your cyrus server is heavily used fall under those
particular circumstances? Or is it normal operations, instead?
What are the valid reasons you found not to use
Rob Siemborski wrote:
On Mon, 14 Mar 2005, Marco Colombo wrote:
Now, can you claim conformance to RFC 2831 if you're using /dev/urandom?
Does the fact that your cyrus server is heavily used fall under those
particular circumstances? Or is it normal operations, instead?
What are the valid reasons
On Mon, 14 Mar 2005, Marco Colombo wrote:
I'm not happy to hear there is a 'large number of deployments' where
RFC 2831 recommandation is violated. The admins of those site should
consider either getting more resources (entropy, in this case) or stop
running any strong but demanding SASL mechanism
Rob Siemborski wrote:
SASL doesn't generate *keys* using this, it generates *nonces*, which
are known to the attacker anyway, since they are transmitted in the
clear anyway. It just matters that they don't repeat often enough to
bother precomputing values for.
If SASL was using this for key
On Fri, 11 Mar 2005, Marco Colombo wrote:
Ok technically speaking SSL/TLS is not part of SASL. But the two are
related. Maybe I'm biased by the fact that most of the connections I see
are SSL+plaintext. So I was referring to SSL keys actually.
Sure, or, say, kerberos keys.
For what SASL is using
Henrique de Moraes Holschuh wrote:
[...]
That scenario assumes a lot of stuff like complete SHA break, complete PRNG
break, capabilities to observe almost all output of the PRNG ordered on
time, etc.
SHA1 break is enough. Guessing the state of the PRNG just requires
observing a very short sequence
On Fri, 4 Mar 2005, Henrique de Moraes Holschuh wrote:
On Thu, 03 Mar 2005, L. Mark Stone wrote:
The POP server component is giving us a problem. It often fails to
respond to connection requests in a timely manner, if at all. IMAP
Disable APOP, or get SASL to use /dev/urandom like it should be
On Thu, 10 Mar 2005, Marco Colombo wrote:
You seem to have too much faith in catastrophic reseeds, btw. If he's
using the same sourcecode of the kernel, _his_ program is going to
perform a reseed at the same time, in the same way. No matter how
No. We assume we have *some* entropy getting in,
Henrique de Moraes Holschuh wrote:
On Thu, 03 Mar 2005, L. Mark Stone wrote:
The POP server component is giving us a problem. It often fails to
respond to connection requests in a timely manner, if at all. IMAP
Disable APOP, or get SASL to use /dev/urandom like it should be doing in any
sane
On Fri, 04 Mar 2005, Marco Colombo wrote:
You do want to use /dev/random for your session keys. _They_ are
likely going to attack your session keys, not your master key. The whole
point is to guess as many bits as possible of the kernel PRNG state.
Which, in a Cyrus server, won't be helpful
Fernando,
Thank you very much, that fixed it!
With best regards,
Mark
On Fri, March 4, 2005 3:36 am, Fernando Arconada Oróstegui said:
Yesterday i had the same problem in SLES9 and i found the solution
disabling APOP in /etc/imapd.conf with allowapop:0
Its a problem with ramdom numbers and
First of all, let me state that I don't really believe that attacking the
internal state of the kernel PRNG is pratical at all. It is possible,
in theory. Using /dev/urandom is pretty safe for many real-world uses.
We're discussing theory here.
Henrique de Moraes Holschuh wrote:
On Fri, 04 Mar
On Fri, 04 Mar 2005, Marco Colombo wrote:
First of all, let me state that I don't really believe that attacking the
internal state of the kernel PRNG is pratical at all. It is possible,
in theory. Using /dev/urandom is pretty safe for many real-world uses.
Which *was* my whole point, that in
I'm running Cyrus 2.2.3 on SuSE Linux Enterprise Server 9, installed
from SuSE's rpm packages.
The POP server component is giving us a problem. It often fails to
respond to connection requests in a timely manner, if at all. IMAP
shows no such problems; IMAP responds to telnet requests very
On Thu, 03 Mar 2005, L. Mark Stone wrote:
The POP server component is giving us a problem. It often fails to
respond to connection requests in a timely manner, if at all. IMAP
Disable APOP, or get SASL to use /dev/urandom like it should be doing in any
sane distribution (SASL is not
trying building cyrus from src...
On Thursday 03 March 2005 06:59 pm, L. Mark Stone wrote:
I'm running Cyrus 2.2.3 on SuSE Linux Enterprise Server 9, installed
from SuSE's rpm packages.
The POP server component is giving us a problem. It often fails to
respond to connection requests in a
17 matches
Mail list logo
