Re: Where do the random numbers come from?

From: Bjoern (bjoern_p1_at_gmx.net)
Date: 02/10/05

  • Next message: Simon Tatham: "Re: Where do the random numbers come from?"
    Date: Thu, 10 Feb 2005 11:30:39 +0100
    
    

    Simon Tatham wrote:
    > Bjoern <bjoern_p1@gmx.net> wrote:
    >
    >>Ah OK, sorry, I guess I confused it with SSL which appears to be the
    >>predecessor of TSL? I'll look into ssh... However, the reason I am not
    >>just using an established protocol is that resources on my client are
    >>limited (mobile phone). The protocols I found are too heavyweight
    >
    >
    > What do you mean by `too heavyweight'? Do you mean you've actually
    > tried them and they run too slowly?

    Speed is an issue, but more important is memory usage. Also the (java)
    application's file size is limited - in one case to 64 KB, and adding
    the classes for RSA and AES makes up for 17KB already. I intend to check
    if I can optimize the source some more, though - it seems the bulk of
    the space is being taken up by the BigInteger class, and I might not
    need all of it's methods. Startup time (initializing the encryption) is
    also relatively long.

    > Which part of the protocol is too slow? You might still gain
    > advantage from reusing the rest. For example, if SSH2's
    > Diffie-Hellman key exchange is too slow for you, you might still do
    > well to substitute an alternative key exchange method but to keep
    > the rest of the protocol, since it has carefully thought through a
    > great many other things that you'd be unlikely to get right on your
    > own.

    That's what I am trying to do, I said 'mimicking' because I only use
    parts of the protocol. I guess there is no problem with AES, what is
    really taking most of the time and memory appears to be the BigInteger
    operations, required for asymmetric encryption.

    > (There is no `f' in `authentication'. You are making sure that
    > somebody is authentic, therefore you are authentic-ating them.)

    Ooops, very embarassing, thanks for pointing that out!

    >>but it seems to me that it takes only 5 minutes to compute an 8
    >>letter password, if you have the hash of login and password - so it
    >>is not secure at all.
    >
    >
    > Where do you get this figure from? I don't understand your reasoning
    > at all. Given an eight-character password, you have perhaps 90
    > possible choices for each character, so your search space is 90^8
    > possible passwords, which is 4304672100000000. If you have a machine
    > that can do that many hash operations in five minutes, I want to buy
    > it from you!

    Thanks again - I was only testing with digits, which is what some of
    companies use (passwords that consist only of digits). But it's
    reassuring to know that using more characters increases the computing
    time so significantly, I should have tried that myself :-/

    > The more interesting problem with HTTP Digest is that it contributes
    > nothing towards the security of the session. Partly this is in
    > confidentiality: HTTP Digest protects your password from an
    > eavesdropper but the subsequent data you transfer once authenticated
    > is readable. But more importantly, the major threat it leaves open
    > is session hijacking: once you've done the exchange of digests and
    > the server is convinced of your identity, a malicious attacker in
    > between you and the server can suddenly insert their own data into
    > your network connection and send their own commands, which will be
    > executed by the server in the assumption that they've come from you.

    Wouldn't it be possible to create a hash over all the commands, not just
    the password, though?

    > This is not a theoretical risk. One of the computers I use was
    > subjected to a real session hijacking attack a few months ago.
    > (Fortunately, we were using SSH and therefore the host key mechanism
    > detected it immediately.)

    I believe you, I think hacking attacks are a very real threat,
    especially as they are often beind conducted automatically. So it is not
      an issue of being an interesting victim or having enemies.

    >>The library just provides the algortithms, though, it is up to me to put
    >>them together. I am asking here because I never read anything about the
    >>random number generation in any of the protocol specifications I found.
    >>Of course you can seed the BouncyCastle random number generator with
    >>anything you want.
    >
    >
    > Random number security is not just a matter of where you get your
    > seed data from (although that is important, of course). Another
    > important consideration is whether the random number generator's
    > internal state can become known.
    >
    > For example, the best-known random number generator used for non-
    > cryptographic purposes is a linear congruential one, in which each
    > output of the generator is derived from the previous output by a
    > simple mathematical formula. This means that if you used it in a
    > hostile environment, an attacker who could see just one _output_
    > from your generator would be able to predict all the subsequent
    > outputs without even needing to try to guess your initial seed.

    I have to check the BouncyCastle algorithm (which is based on SHA1), but
    since they go at lenghts to provide a SecureRandom class rather than
    just Random, I think they have taken this into consideration.

    Many thanks for your comments!

    Bjoern


  • Next message: Simon Tatham: "Re: Where do the random numbers come from?"

    Relevant Pages

    • Re: Where do the random numbers come from?
      ... Which part of the protocol is too slow? ... Diffie-Hellman key exchange is too slow for you, ... key exchange so that an attacker can't fake it. ... the best-known random number generator used for non- ...
      (comp.security.ssh)
    • [NEWS] SSH Protocol Weakness Vulnerability (MITM)
      ... A weakness in the backward compatibility of the SSH Protocol has been ... SSH version 1.0) is unlikely to have the host key for the other protocol ... The SSH daemons advertise one of two major versions, ...
      (Securiteam)
    • SUMMARY: SSH 2.5.2p2 on Tru64 4.0g
      ... SSH is very particular about the permissions on the $HOME/.ssh ... Always pay particular attention the the ssh SERVERs protocol usage. ... when only using the identity.pub or rsa key. ... file on the remote host to reflect the host name without domain that was ...
      (Tru64-UNIX-Managers)
    • Re: SOCKS 5 protocol & sysadmin
      ... bypassing proxy settings using SOCKS 5 protocol? ... example SSH he can tunnel almost any TCP protocol into it and you will ... By the way, Even without SSH access, Any other opened port can be used ...
      (comp.os.linux.security)
    • Re: how to react on ssh attacks?
      ... > I recently checked my log files of my ssh service (so far as I ... these attacks will get more sophisticated as time goes on - the ... Protocol 2,1 line in /etc/ssh/sshd_config to say Protocol 2 and then ... Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org ...
      (Fedora)