Re: randomdev entropy gathering is really weak
On Sun, Jul 23, 2000 at 03:06:34PM +0200, Poul-Henning Kamp wrote: > In message <[EMAIL PROTECTED]>, Stefan `Sec` Zehl writes: > >With the current approach it has a 256bits key. This is, in my eyes, not > >good. Although yarrow is nice, It's suited for any kind of key > >generation. > > The first law of crypto clearly states: "Know what you're doing". > > There is no way around that law. > > We cannot load down FreeBSD with impossibly heavy computations to > cater for any and all conceiveable application of random numbers. But FreeBSD should provide a way to get truely random numbers when it asks for them. /dev/random was invented so the applications don't have to bother with entropy-gathering. I agree that yarrow is good, but we need some way to get really random numbers. Maybe call it /dev/rrandom. The way Kris describes it, it won't really use cpu time until it is read. CU, Sec -- > I even remember having a private exchange of messages with you about other > possible approaches to that problem. :-) Hopefully, these approaches involved slowly crushing of tender body parts. -- Liviu & Wietse about broken Mailers ~ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: randomdev entropy gathering is really weak
Poul-Henning Kamp <[EMAIL PROTECTED]> wrote: > In message <[EMAIL PROTECTED]>, Kri > s Kennaway writes: > >On Sun, 23 Jul 2000, Poul-Henning Kamp wrote: > > > >> Obviously, if you need more randomness than a stock FreeBSD system > >> can provide you with, you add hardware to give you more randomness. > > > >This won't help if it's fed through Yarrow. > > Nobody has said anything about forcing you to use Yarrow, have they ? If FreeBSD delivers with it, it will get used. I think Kris has a valid concern. If I assume that I will get good randomness from /dev/random, and I don't, there is potential danger. Assume I want to encrypt a message by XOR'ing with randomness. If I then exchange my keys securely, the message is uncrackable. With the current approach it has a 256bits key. This is, in my eyes, not good. Although yarrow is nice, It's suited for any kind of key generation. > I have not seen any new information in the last N emails from you. This is because his concerns aren't addressed yet. CU, Sec -- Das Usenet ist so ein wunderbares, aber zerbrechliches Medium und so viele treten es so in den Dreck und machen es unbenutzbar - sei es durch Absicht oder Gedankenlosigkeit, was vom Ergebnis das gleiche ist. -- Bettina Fink To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ftp 10.10
On Mon, Feb 07, 2000 at 11:05:55AM +0900, Yoshinobu Inoue wrote: > > marc> With ping it is still functioning. I cannot find what changed this. > > marc> cvs messages for Changes to /usr/src/usr.bin/ftp/util.c of 18 and 20 > > marc> Jan do not mention it. So maybe somewhere else to look? > > > > Several applications which support both IPv4 and IPv6, such as > > telnet/ftp, has used getaddrinfo() for resolving hostnames. > > > > If IPv4 dotted-decimal forms are given, getaddrinfo() calls finally > > inet_pton(). inet_pton() is defined in RFC2553 and it does not permit > > non-standard IPv4 dotted-decimal, such as 10.10 > > Do people have troubles with this change? While the most cases I use it, are 10.1 and 127.1 I would miss it very much. More so, because I don't see why this functionality should be removed. It doesn't break anything else, IMHO. CU, Sec -- This article doesn't really cover many specifics, other than to point out that these pieces of equipment which have been labeled completely obsolete, still have value and function, and not only to the hacker. -- hir4-5.txt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: net.inet.tcp.always_keepalive on as default ?
On Sat, Jun 05, 1999 at 07:37:57AM +0200, Poul-Henning Kamp wrote: > QED: The following patch. [...] > +tcp_keepalive="YES" # Kill dead TCP connections (or NO). I still don't understand why you insist on making it YES by default. It works fine like it is for most of the people right now. So why shouldn't the few servers which have problems without it, enable it? Make it a knob in rc.conf but off by default. As I understand it, It suffices if the server requests the keepalives. So if every FreeBSD-box has it on by default, I simply can not choose to have no keepalifes anymore, even if I turn them off locally. So this change is going to hurt somebody, somewhere. CU, Sec -- One of the main causes of the fall of the Roman Empire was that, lacking zero, they had now way to indicate successful termination of their C Programs. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: net.inet.tcp.always_keepalive on as default ?
On Fri, Jun 04, 1999 at 10:21:05PM +0200, Matthew Dillon wrote: > Around 0.02%, using the stats from one of BEST's busier servers. > That's percent. > > In otherwords, nobody would notice. You wouldn't notice, the backbones > wouldn't notice... nobody would notice. I would. I have several long-lived connections, with a few of them are sometimes unreachable for quote some time. I like that they survive, and would hate it, if some brain-dead default would ruin my perfectly set up connections. Even more, it would ruin dial-on-demand for a lot of people, i think. CU, Sec -- The Feynman problem solving Algorithm 1) Write down the problem 2) Think real hard 3) Write down the answer To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: /boot/loader problem with unusual setup.
On Wed, Jan 13, 1999 at 10:00:48PM +0100, Andrzej Bialecki wrote:
> Where ${rootdev} points to? Shouldn't you set it accordingly to disk3s1a:?
rootdev isn't set at all (as show says).
I can't imagine that this will make a change, as I am booting from
disk3, the problem stems from FreeBSD not realizing that this is wd0, i
think.
In fact, I tried it out, and it didn't help :-(
CU,
Sec (happy that the new bootblock also supports elf kernels)
--
Aufgrund eines Bugs in unserem Newsserver ist es nicht moeglich,
diesen offensichlich versehentlich geposteten Artikel zu canceln.
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
