On Tue, 17 Dec 2002, Hubert Chan wrote:
> Philip> 2. Does ssh only use urandom once, that is to generate keys while it
> is
> Philip> configuring? Again I have assumed yes.
>
> I don't think the public/private key (i.e. host key) generation is much
> of an issue, since one should be able to gen
> "Philip" == Philip Charles <[EMAIL PROTECTED]> writes:
Q1, I don't know the answer to, but I believe that your guess is right.
[...]
Philip> 2. Does ssh only use urandom once, that is to generate keys while it is
Philip> configuring? Again I have assumed yes.
I don't think the public/pr
On Wed, Dec 18, 2002 at 12:53:23AM +0100, Gaël Le Mignot wrote:
>
> I totally agree with this idea. For a while at least, having a
> 'hurd-extras' package with some unfished translators like random,
> httpfs or whatever could be very usefull. And we just have to add a
> hurd-specif
On 17 Dec 2002, Thomas Bushnell, BSG wrote:
> Ssh should provide a non-cryptographically secure mode (such as using
> hashes of the low time bits, for example) for use on systems without a
> real random bit source.
>
> If it does not use that, it is reasonable for us to use a hack to
> provide som
No, we should use a random translator, which, at least, provide
uniform numbers, and differents number on successive reads.
Why do I feel like repeating this old mantra: Bad security is worse
than no security.
I totally agree with this idea. For a while at least, having a
'hurd-extras' package with some unfished translators like random,
httpfs or whatever could be very usefull. And we just have to add
a hurd-specific dependancy on ssh to hurd-extras for our current
problem.
Would you li
Ssh should provide a non-cryptographically secure mode (such as
using hashes of the low time bits, for example) for use on systems
without a real random bit source.
What Open SSH should do and not do, should be discussed on the Open
SSH mailing list, not here.
Neal a écrit :
>> > Your argument is absurd. Network security considerations are different
>> > than local system security considerations. We have control over who can
>> > have an account on our systems. We don't necessarily have control over
>> > who has access to our IP ports.
>>
>>
Wolfgang a écrit :
>> Now, could somebody point a quick tutorial (for impatient people)
>> on creating debian packages? Maybe we (or maybe kilobug?) could
>> create an ssh debian package and put it somewhere (I would love
>> to mirror it).
> `ssh package'? You are confused. I think you ac
"Alfred M. Szmidt" <[EMAIL PROTECTED]> writes:
>I agree that we should not have a fictitious /dev/urandom, but we
>should support ssh even so.
>
> Open SSH is supported, in an insecure way, by either a random
> translator, or the copying hack.
Ssh should provide a non-cryptographically s
On Wed, Dec 18, 2002 at 05:24:40AM +0700, Budi Rahardjo wrote:
> I guess most of you work on the GNU/Hurd in front of consoles,
> thus have no problem having no ssh (or assume that people could
> install it themselves). Fair enough...
I am using telnet. :)
> Now, could somebody point a quick tuto
> > Your argument is absurd. Network security considerations are different
> > than local system security considerations. We have control over who can
> > have an account on our systems. We don't necessarily have control over
> > who has access to our IP ports.
>
> These are all excellent reaso
Has everyone forgotten what this discussion actually about? We are
not talking about removing the Open SSH deb! We are talking about
adding ugly hacks like a broken random translator, or copying files
in-place of /dev/urandom.
I agree that we should not have a fictitious /dev/urandom, but we
should support ssh even so.
Open SSH is supported, in an insecure way, by either a random
translator, or the copying hack.
None of them are reasons to remove functionality.
No functionality is being removed.
On Wed, Dec 18, 2002 at 05:24:40AM +0700, Budi Rahardjo wrote:
> PS: is there anybody working on sendmail package? it compiles clean
> under GNU/Hurd.
Last I checked there were several dependencies that did not compile
cleanly. =( It's been about a year since I tried, though.
Tks,
Jeff Bailey
Ok. We all have read views from both sides. Let's stop the flames.
I guess most of you work on the GNU/Hurd in front of consoles,
thus have no problem having no ssh (or assume that people could
install it themselves). Fair enough...
Now, could somebody point a quick tutorial (for impatient people)
"Alfred M. Szmidt" <[EMAIL PROTECTED]> writes:
>Really, I don't think we delete packages just because we have bugs.
>We have *lots* of bugs, and it's inappopriate to remove packages as
>if we were a production system.
>
> Delete what exactly? We were talking about _adding_ a package.
Jeff Bailey <[EMAIL PROTECTED]> writes:
> On Tue, Dec 17, 2002 at 11:07:35AM -0800, Thomas Bushnell, BSG wrote:
>
> > > Without ext2fs the system is completly unusable, without random the
> > > system is quite usable. Without GNU Mach you don't even have a
> > > working system.
>
> > But you sa
[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes:
> Why do you think it would necessarily be too slow?
Well, of course it creates `some' overhead, since it is another layer
on top of the real filesystem, through which path lookups are routed.
I am not sure, wether that is already too much overhead
But you said that "bad security is worse than no security". So
better no GNU Mach than an insecure one, right?
A system works just fine without a random translator, it does not work
at all without an secure, or insecure kernel. A random translator is
_not_ a crucial part of an system, a ke
On Tue, Dec 17, 2002 at 11:07:35AM -0800, Thomas Bushnell, BSG wrote:
> > Without ext2fs the system is completly unusable, without random the
> > system is quite usable. Without GNU Mach you don't even have a
> > working system.
> But you said that "bad security is worse than no security". So b
"Alfred M. Szmidt" <[EMAIL PROTECTED]> writes:
> Without ext2fs the system is completly unusable, without random the
> system is quite usable. Without GNU Mach you don't even have a
> working system.
But you said that "bad security is worse than no security". So better
no GNU Mach than an insec
Moritz Schulte <[EMAIL PROTECTED]> writes:
> Michal 'hramrach' Suchanek <[EMAIL PROTECTED]> writes:
>
> > - the separation of partitions should be solved by union(shadow)fs
> > and not directories
>
> I have one doubt about using a unionfs as root filesystem:
> performance.
Why do you think i
Alfred a écrit :
>With allowing GNU/Hurd _users_ to _use_ an ssh client.
> What exactly prevents them from not using it? They can download the
> random translator and use it,
If they know where to find it. And it's a waste of time. And it makes things
more complex and tricky than they
With allowing GNU/Hurd _users_ to _use_ an ssh client.
What exactly prevents them from not using it? They can download the
random translator and use it, they can use the copying hack. Nothing
prevents them from not usin ssh. It also makes them aware that it is
insecrue, adding it hides this
Alfred a écrit :
>Why there are problems to enhace GNU/Hurd?
> Enhance the Hurd how exactly? With flawed security?
With allowing GNU/Hurd _users_ to _use_ an ssh client.
>Sooner or later hurd/random(?) server will be added to the base
>system...why not now?
> Because it is br
Why there are problems to enhace GNU/Hurd?
Enhance the Hurd how exactly? With flawed security?
Sooner or later hurd/random(?) server will be added to the base
system...why not now?
Because it is broken (in the sense of no good entropy source). Fix the
problems, and it might get added.
On Tue, Dec 17, 2002 at 12:42:59PM +0100, Alfred M. Szmidt wrote:
>I support the addition of ssh, *even* with a weak random.
>
> There was never any talk about removing ssh.
>
>Now, what's current best practice? We use this:
> http://kilobug.free.fr/hurd/random-64.tar.gz
>Is the
> Open SSH does collect its own random data (from ps, and whatever else)
> + from /dev/random and /dev/urandom. Now, why does it _have_ to use
> /dev/urandom? Ask the OpenSSH people. :)
/dev/urandom is _not_ cryptographically secure random data. It's fast, cheap
random data. Not
Alfred a écrit :
>I find it a little odd that you need to have /dev/urandom for
>openssh to work, I thought openssh was ported to plenty of systems
>that don't have and never had any /dev/u?random.
> Open SSH does collect its own random data (from ps, and whatever else)
> + fro
Alfred a écrit :
>I support the addition of ssh, *even* with a weak random.
> There was never any talk about removing ssh.
>Now, what's current best practice? We use this:
> http://kilobug.free.fr/hurd/random-64.tar.gz
>Is there a better alternative(s)?
> Or you can cop
I find it a little odd that you need to have /dev/urandom for
openssh to work, I thought openssh was ported to plenty of systems
that don't have and never had any /dev/u?random.
Open SSH does collect its own random data (from ps, and whatever else)
+ from /dev/random and /dev/urandom. No
I support the addition of ssh, *even* with a weak random.
There was never any talk about removing ssh.
Now, what's current best practice? We use this:
http://kilobug.free.fr/hurd/random-64.tar.gz
Is there a better alternative(s)?
Or you can copy /bin/bash to /dev/urandom, they are
Michal 'hramrach' Suchanek <[EMAIL PROTECTED]> writes:
> - the separation of partitions should be solved by union(shadow)fs
> and not directories
I have one doubt about using a unionfs as root filesystem:
performance.
moritz
--
[EMAIL PROTECTED] - http://duesseldorf.ccc.de/~mo
"Alfred M. Szmidt" <[EMAIL PROTECTED]> writes:
> Strong security that uses encryption like DSA/RSA depends on a good
> entropy source of random bits, we don't have one.
And it's particularly nasty with DSA. If you create DSA signatures
with a bad randomness generator, you risk leaking your privat
Philip a écrit :
> The warning displayed at the end of total.sh
> echo "A file needs to be copied to /dev/urandom before ssh will configure"
> echo "then run . Security will be poor unless the file"
> echo "consists of random material."
Copying a file is even worse random data than using t
38 matches
Mail list logo
