Re: Feature request

From: Darren Tucker (dtucker_at_dodgy.net.au)
Date: 10/03/04

  • Next message: PerlBoy: "Re: Feature request" 
    Date: Sun, 3 Oct 2004 05:29:55 +0000 (UTC)

    In article <cjn7g2$9i$1@news.cistron.nl>,
    PerlBoy <nu-ff-niet@geen-idee.nu> wrote:
    [about ssh private key files]
    >Do I understand it correctly that the file on disk is the private key minus
    >the passphrase?

    No, the private key file on disk is the private key encrypted with the
    passphrase. The private key is (in the case of RSA) just a big number
    corresponding to the numbers representing the public key, stored as a
    binary blob. The passphrase can be changed (ie decrypt then re-encrypt
    the blob) without changing the key ("ssh-keygen -p" for OpenSSH).

    >Okay, but the passphrase belongs to the private keyfile. I wish we could
    >lock the private key for a known to be strong passphrase.

    You can't unless you control the hardware and software accessing the
    private key. This is a "smartcard", and several vendors sell them.

    [...]
    >Very good point.... I think the whole private keyfile should be sent. But
    >how do you do that secure?

    You do it securely by not doing it. By definition, it is *not* secure.
    It's a terrible idea. A single compromised host could capture the private
    key, conduct an offline attack on the passphrase and compromise *all*
    hosts with the corresponding public key.

    >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 :-(

    What you're asking for is equivalent to wanting telnetd/login to
    reject passwords if the user writes them down on a sticky-note. It's a
    people/policy problem not a technical problem. 

    -- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.
  • Next message: PerlBoy: "Re: Feature request"

    Relevant Pages

    • Re: Feature request
      ... >>case why can that not be send across on request in the handshake phase? ... > change his private key in any way, he could no longer be authenticated ... the passphrase is ... but the passphrase belongs to the private keyfile. ...
      (comp.security.ssh)
    • 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: Feature request
      ... >>the passphrase? ... the private key file on disk is the private key encrypted with the ...
      (comp.security.ssh)
    • Re: Crypto Question
      ... > the passphrase used for the private key? ... > 'password' then does it become irrelevant what key size I use to encrypt ... is only supposed to protect the private key. ... PGP / XML GATEWAY APPLIANCE ...
      (Security-Basics)
    • Re[2]: Crypto Question
      ... N> If I'm not mistaken, though, the passphrase on the PGP private key is ... N> simply a bit of symmetric-key encryption to help protect your private ... N> I've never really looked at the internal workings of PGP (but I ...
      (Security-Basics)