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:
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:
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 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.
Fo
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 it
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 ge
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
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 do
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, 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
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 2005
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 an
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
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 d
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 i
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 genera
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 fa
17 matches
Mail list logo