Re: /dev/random is probably not

From: ChayoteMu (chayotemu_at_gmail.com)
Date: 07/06/05

  • Next message: Thomas: "Re: /dev/random is probably not"
    Date: Tue, 5 Jul 2005 16:25:11 -0700
    To: Glynn Clements <glynn@gclements.plus.com>
    
    

    It's not necessarily the traffic itself, but aspects of the traffic.
    Someone had mentioned that the timing between recieving the packets
    was what's used, even if you see that it may change over the rest of
    the wire and there's nothing to say that the system is using all the
    traffic as the attacker sees it. Drop every 5th packet and hash the
    result with the time and the attack doesn't have anything to work
    with. Just because you can observe or control one aspect doesn't mean
    you can observe/control the entire thing.

    On 7/5/05, Glynn Clements <glynn@gclements.plus.com> wrote:
    >
    > "Zow" Terry Brugger wrote:
    >
    > > It's been a while since I looked at the /dev/random design on Linux
    > > (probably the early 2.4 days), however one thing that was quite
    > > clear was that they did not use any network I/O as entropy sources
    > > because an attacker, particularly one that already had control of
    > > other machines on the same LAN segment, could have a high degree of
    > > control over that source.
    >
    > They don't need to have any control; simply being able to observe
    > network traffic means that it is no longer random (in the sense of
    > "unpredictable", which is what counts from a security perspective).
    >
    > --
    > Glynn Clements <glynn@gclements.plus.com>
    >

    -- 
    "To catch a thief, think like a thief. To catch a master thief, be a
    master thief."
    

  • Next message: Thomas: "Re: /dev/random is probably not"

    Relevant Pages

    • Re: IPS with no IP address?
      ... concept of the stackless control channel. ... Basically directing control ... Stackless Control Channel - AES encrypted packets directed through the ... Recognizer - Code running on the appliance capable of interpreting ...
      (Focus-IDS)
    • Re: Netmap ixgbe driver problem on 10Gbps X540-AT2 adapters (Linux only?)
      ... Control: RX/TX ... Sent 100000 packets, 60 bytes each, in 28.42 seconds. ... Ethernet Controller 10 Gigabit X540-AT2 ... capabilities: pm msi msix pciexpress vpd bus_master cap_list rom ...
      (freebsd-net)
    • Re: Netmap ixgbe driver problem on 10Gbps X540-AT2 adapters (Linux only?)
      ... actually for me it was necessary to set -w 6 to avoid the adapter reset ... Sent 100000000 packets, 60 bytes each, in 11.27 seconds. ... Control: RX/TX ... capabilities: pm msi msix pciexpress vpd bus_master cap_list ...
      (freebsd-net)
    • Default behaviour of IP Options processing
      ... I have just committed the attached change to ip_inputto control the ... stamp) which are both useless. ... > net.inet.ip.process_options=0 Ignore IP options and pass packets unmodified. ... > This sysctl affects packets destined for the local host as well as those ...
      (freebsd-current)
    • Default behaviour of IP Options processing
      ... I have just committed the attached change to ip_inputto control the ... stamp) which are both useless. ... > net.inet.ip.process_options=0 Ignore IP options and pass packets unmodified. ... > This sysctl affects packets destined for the local host as well as those ...
      (freebsd-net)