Re: Feature request

From: PerlBoy (nu-ff-niet_at_geen-idee.nu)
Date: 10/02/04 

Date: Sat, 2 Oct 2004 23:44:29 +0200

Thanks Per for the constructive reply. I have some more comments/questions
below

Niels.

"Per Hedeland" <per@hedeland.org> wrote in message
news:cjlsni$1heo$1@hedeland.org...
> In article <cjgapo$7b8$1@news.cistron.nl> "Niels van Dijke"
> <nu-ff-niet@geen-idee.nu> writes:
> >
> >"Richard E. Silverman" <res@qoxp.net> wrote in message
> >news:m23c10piwm.fsf@darwin.oankali.net...
> >> >>>>> "PB" == PerlBoy <nu-ff-niet@geen-idee.nu> writes:
> >>
> >> PB> I like to lockdown installed public keys by adding a
> >> PB> 'fingerprint="xx:xx:xx....:xx" option to it.
> >>
> >> I don't understand. The fingerprint is a function of the key; this
adds
> >> no information.
> >
> >Isn't it so that the fingerprint a MD5 sum is of the private key? If that
is
> >case why can that not be send across on request in the handshake phase?
As
> >long as the MD5 algorithm hasn't been broken, this should be safe to do.
>
> The fingerprint is computed from the public key - but your idea wouldn't
> be any more useful if it was computed from the private key: The
> fundamental basis for public/private key cryptography is that the key
> pairs are "unique" - a given public key can only ever be used with the
> corresponding private one and vice versa. I.e. if the user were to
> change his private key in any way, he could no longer be authenticated
> by the public key that you have on the server. (N.B. the passphrase is
> not part of the key.)
>

Do I understand it correctly that the file on disk is the private key minus
the passphrase?

> >> PB> The user will receive a private key (file download in browser)
and
> >> PB> the webserver keeps the public key and the belonging
fingerprint.
> >>
> >> This should *never* happen; people generate their own private keys, so
> >> they know they are indeed private. What do you think you gain by
> >> generating them yourself?
> >
> >Why should this *never* happen? I'm responsible for the servers I manage.
>
> Because it's a bad idea to ship secret things around and needlessly
> store them in multiple places.

We will not keep them on the webserver. We only want to enforce its
strength.

>
> >Okay, I can try to refuse to create accounts. But management will overule
> >this by default. If the key is for business use only then to my opinion
this
> >key does not have to be secret to the user only by default.
>
> You gain nothing by having knowledge of what the secret key is, see
> above - but obviously you could lose a lot if a third-party manages to
> get hold of it due to flaws in your creation/distribution/storage
> methods.
>
> > We have syslog
> >standard on 'info' level and have therefor the fingerprint logging. For
> >auditing by it self would the fingerprint option in the authorized_keys
be
> >great.
>
> No, it's useless, see above.
>
> >If we generate the key ourselves we have control over the strength
(length
> >and randomness).
>
> You may possibly have a point regarding the randomness, but I believe
> most key-generation SW does a good job of ensuring that - and unless you
> use cryptographic HW, simply having the knowledge that the key was
> generated on a specific server at a specific time may at least
> theoretically increase the probability of a successful attack over the
> case where it was done on some random end-user host at an unknown point
> in time. All in all, probably won't outweigh the cons above.
>

Our users currently use their own ssh-keygen and therefore provide their own
strong or weak passphrase.

> The length can be determined from the public key alone of course, so you
> just need to make that a requirement and refuse to accept public keys of
> a shorter length.
>

All key lengths (512, 1024, 2048 and 4096) are okay by us. All strong enough
for brute force attacks.

> > With the fingerprint matching a user would not be able to
> >weaken their passphrase without notifying the sysadmin (assuming that
they
> >can not change their own authorized_keys file).
>
> No, the fingerprint is quite independent of the passphrase.

Okay, but the passphrase belongs to the private keyfile. I wish we could
lock the private key for a known to be strong passphrase. Hence my request
for a private keyfile fingerprint (optionally requested) in the initial
handshake.

>
> Hm, it seems maybe you actually think that the fingerprint is just a
> straight MD5 sum of the private key file as stored on disk. It isn't,
> obviously (and couldn't be used for its intented purposes if it were),
> but such a thing could possibly be used for the purposes you consider
> above. On the other hand a given private key with a given passphrase is
> likely to yield different such MD5 sums depending on type of client SW
> and OS - there is no standard for how keys are stored on disk, and as
> far as I know not even for how the passphrase is used to encrypt them.

A private keyfile represents a binary string right? Also WE provided the
keyfile and should therefore be accepted by the user's SW. Maybe I'm asking
something which requires to boost the protocol to version 3. Who knows?

>
> And of course strictly speaking, if you don't trust the user to manage
> his key securely, you also couldn't trust that he didn't modify his
> client SW to send your "expected" MD5 sum regardless of what is actually
> in his key file.

Very good point.... I think the whole private keyfile should be sent. But
how do you do that secure? After initial handshake? And how do you know that
this file isn't spoofed?

>
> But this last part is all academic anyway - ssh client SW doesn't send
> or even compute such an MD5 sum, so there's no way the server can verify
> it.

Pity! I really love/hate passphrases. They can be very long and strong but
also very short or empty.... It would be nice if SSH developers/encryption
specialist would take look into this feature request, because if we have no
means of controlling passphrase strengths in the future then I think we are
doomed to switch them of by corporate security :-(

>
> --Per Hedeland
> per@hedeland.org

Relevant Pages

  • Re: Client certificate private key prompt
    ... this when they need to make sure that no request every goes as anonymous. ... Upgrading the client to W2K3 will not solve the two prompt issue. ... the private key. ...
    (microsoft.public.dotnet.framework)
  • RE: SIMple SSL question ??
    ... The private key is not passed in the certificate request, ... so the attacker cannot decrypt incoming messages or sign outgoing ones. ... When IIS is used to create a certificate request, ...
    (microsoft.public.dotnet.security)
  • Re: SSH publickey auth
    ... > The goal of using Identity/Pubkey authentication is to remove the need ... > can prove you have the public and private key then you are granted ... You see here the mention of the "passphrase"? ... > authentication credentials 'follow' you. ...
    (Fedora)
  • Re: Interfacing key archival CMC request to a non .net CA
    ... If xenroll is used to construct the CMC request and attach the encrypted ... private key blob sent to the server. ... If the request is wrapped inside another PKCS7 layer as part of a nested CMC ... The closest match> "Encrypted Hash" is only the size of a RSA encryption, so can not> directly contain a full private key. ...
    (microsoft.public.platformsdk.security)
  • Re: IIS 6.0 SSL Certificate Difficulties
    ... that is just a plain text file with encrypted detail of your server detail. ... do you export the private key as well? ... > certificate from the IIS Snap-in it says that "You have a private key that ... > Another symptom is that when we create the request on the 2003 server, ...
    (microsoft.public.inetserver.iis)