6 ms·

is sleep(1) noisy? if so, it might be vs timing attacks

typedef_void 16y ago
on second thought, my comment makes little sense, if they wanted noisy sleep, it should be something like sleep(func(rand()))
- JoachimSchipper 16y ago
  That makes no sense either, an attacker can usually average such things out. Besides, there are better (faster) ways to guard against timing attacks.
  - daeken 16y ago
    People seem to have a skewed perception of how to defeat timing attacks, generally. At the end of the day, it's more about making things constant time than trying to make the timing difficult to detect. Simple example: You have two hashes and want to see if they're equal. The naive approach is to iterate over each byte in both hashes and compare them, then break when you find a byte that doesn't match. That approach, however, could be vulnerable to a timing attack because you could potentially measure how many times it iterates. An implementation that's resistant to timing attacks could XOR each byte of each hash and accumulate across them; if that accumulator is zero at the end of the loop, it's equal. That approach is constant time, rather than being dependent on the data you're dealing with.
  - fexl 16y ago
    Besides, I see no evidence that the sleep was intended to thwart timing attacks. It looks like it's all about easing the debug process somehow. Incidentally, the primary problem here is not the mere presence of a debug flag that governs a sleep, it's the fact that PySSL_SSLdo_handshake sets that debug flag. Right? In other words, it's not a bug in OpenSSL itself, but rather the Python wrapper for OpenSSL. That's how I understand it.
    - JoachimSchipper 16y ago
      Yes, exactly.
ComputerGuru 16y ago
Sleep is noisy. When you do sleep, depending on the hardware, the OS, the configuration, the kernel flags, etc. the minimum you actually get is around 38. But that varies.
- tptacek 16y ago
  Wait, what? If I call sleep(1), you're saying it's going to sleep for THIRTY EIGHT SECONDS? People, it's right there in the man pages. Are you maybe thinking about WinAPI's Sleep? That's ms-denominated. It would make sense that attempting to sleep for 1 millisecond wouldn't work, and would build in the time for the scheduler and the timeslices for every other process. We're talking about OpenSSL and POSIX sleep(3).
  - ComputerGuru 16y ago
    My apologies. Yes, I do mean MS - I started off doing *nix development, but now am doing Win32 programming 18 hours a day. Please discard my above comment, everyone.
jakevoytko 16y ago
Sleep(1) is very noisy on Windows machines. The time slice given by default is ~15-20ms [1], and calling Sleep(<15) relinquishes the rest of the time slice. Windows has a multimedia API that can be used to get intervals down to 1ms, but it requires system calls that increase your system load. So you usually just need to use proper synchronization anyways, which is what the Python guys should have done :) This crummy Sleep() implementation has some nice effects on programmers. Those who like to solve problems with lots of copy/paste code are forced to think about using proper synchronization primitives when running high resolution loops that wait for events, or their code just won't run very fast. [1] http://social.msdn.microsoft.com/forums/en-US/clr/thread/facc2b57-9a27-4049-bb32-ef093fbf4c29/ http://social.msdn.microsoft.com/forums/en-US/clr/thread/fac...
- bd 16y ago
  Aha, so that's probably why JavaScript timers on Windows have around 15ms accuracy: http://ejohn.org/blog/accuracy-of-javascript-time/ http://ejohn.org/blog/accuracy-of-javascript-time/
- drawkbox 16y ago
  True however Sleep on windows is different than sleep on posix/unix. Sleep() on windows takes ms. sleep() on nix takes seconds. Windows: VOID WINAPI Sleep( __in DWORD dwMilliseconds ); Sleep(1) is as fast as it can go which turns out to be 15-20ms. nix: #include <unistd.h> unsigned int sleep(unsigned int seconds); usleep() can be used for more granular delay on nix.
- Xurinos 16y ago
  When I did driver programming in Windows, it was well-known that Sleep had a resolution of 10 ms; it is based on the interrupt timer (not the high frequency timer). You could change the interrupt timer's duration, but its ticks are what guide Sleep. Not counting the effect of context switching, since you are waiting for the timer ticks, your actual times vary from 10 ms to 19.9999 ms. 15 ms is a nice way to say "on average", but I would not rely on that measure. Timers are hard to get right. Tread warily, programmers! This is one of those areas where it is good to understand some things about the computer hardware behind the software. EDIT: I should add that the high frequency timer is not a panacea either. It will work for you most of the time, but there are two circumstances that will occasionally trip you: (1) At least in Windows XP and 2000, there is a KB (I do not remember it now) that explains that for a certain small set of manufacturers, if there is a sudden spike in high load on the PCI bus, the high frequencer timer will be jumped ahead to account for the lost time during that laggy spike. This correction is not accurate. This means that if your initial timestamp is X, and you are waiting for it to be X+Y, wall clock time may be between X and X+Y, but Windows itself altered the timestamp to be X+Y+Z, and your software thinks the time has elapsed. I personally experienced this bug. (2) You actually have more than one high frequency timer -- one for each CPU on your system. Once you start playing on a system with multiple CPUs, how do you guarantee that the API is providing you a timestamp from the same timer? I remember there may have been way to choose if you dropped to assembly to make the query but that the API at the time did not support a choice. The timer starts upon power-up. If one CPU powers up after the other, you will have a timestamp skew. Some high frequency software algorithms attempt to correct for this skew. I do not know all the details to that now.
igravious 16y ago
Excuse my ignorance: what do you mean by noisy?
- mustpax 16y ago
  Noisy means there is a lot of variance in the actual time the process spends sleeping. When you say sleep(1) most OSes interpret that as saying, sleep as short as you can. Based on the scheduler internals, that can vary a lot.
  - tptacek 16y ago
    Which OS interprets sleep(1) (ie, "sleep for 1 second") as "sleep for as short as you can"? On WinAPI, Sleep is denominated in milliseconds. On BSD, sleep(3) is a library wrapper around nanosleep(2). Linux's man pages make no mention of the magic number "1" as a "sleep 1 timeslice" shortcut; also, older Linux man pages warn that sleep(3) can be implemented in terms of alarm(1), which is used all over POSIX as an I/O timeout and would blow up the world if it alarmed in milliseconds. If you want to sleep "as short as you can", sleep for 0 seconds, or call any other system call to yield your process back to the scheduler.
    - xpaulbettsx 16y ago
      Windows also only guarantees that your process will sleep at least as long as you specify. Not that it will sleep exactly as long.
    - mustpax 16y ago
      Thanks for the correction. I was just talking about the de facto behavior I have seen on Linux and BSD for very short sleep intervals (way shorter than 1 second), not necessarily about the behavior as specified by the system call. I should have been clearer.
      - tptacek 16y ago
        I really don't think you've ever seen BSD return in milliseconds after a 1-second sleep. Respectfully, I think you're pretty much just wrong.
tptacek 16y ago
This has nothing to do with timing attacks and would do nothing to defend against them. Read 'daeken's comment below, though.

on second thought, my comment makes little sense, if they wanted noisy sleep, it should be something like sleep(func(rand()))

JoachimSchipper 16y ago
That makes no sense either, an attacker can usually average such things out. Besides, there are better (faster) ways to guard against timing attacks.
- daeken 16y ago
  People seem to have a skewed perception of how to defeat timing attacks, generally. At the end of the day, it's more about making things constant time than trying to make the timing difficult to detect. Simple example: You have two hashes and want to see if they're equal. The naive approach is to iterate over each byte in both hashes and compare them, then break when you find a byte that doesn't match. That approach, however, could be vulnerable to a timing attack because you could potentially measure how many times it iterates. An implementation that's resistant to timing attacks could XOR each byte of each hash and accumulate across them; if that accumulator is zero at the end of the loop, it's equal. That approach is constant time, rather than being dependent on the data you're dealing with.
- fexl 16y ago
  Besides, I see no evidence that the sleep was intended to thwart timing attacks. It looks like it's all about easing the debug process somehow. Incidentally, the primary problem here is not the mere presence of a debug flag that governs a sleep, it's the fact that PySSL_SSLdo_handshake sets that debug flag. Right? In other words, it's not a bug in OpenSSL itself, but rather the Python wrapper for OpenSSL. That's how I understand it.
  - JoachimSchipper 16y ago
    Yes, exactly.

ComputerGuru 16y ago

Sleep is noisy. When you do sleep, depending on the hardware, the OS, the configuration, the kernel flags, etc. the minimum you actually get is around 38. But that varies.

tptacek 16y ago
Wait, what? If I call sleep(1), you're saying it's going to sleep for THIRTY EIGHT SECONDS? People, it's right there in the man pages. Are you maybe thinking about WinAPI's Sleep? That's ms-denominated. It would make sense that attempting to sleep for 1 millisecond wouldn't work, and would build in the time for the scheduler and the timeslices for every other process. We're talking about OpenSSL and POSIX sleep(3).
- ComputerGuru 16y ago
  My apologies. Yes, I do mean MS - I started off doing *nix development, but now am doing Win32 programming 18 hours a day. Please discard my above comment, everyone.

jakevoytko 16y ago

Sleep(1) is very noisy on Windows machines. The time slice given by default is ~15-20ms [1], and calling Sleep(<15) relinquishes the rest of the time slice. Windows has a multimedia API that can be used to get intervals down to 1ms, but it requires system calls that increase your system load. So you usually just need to use proper synchronization anyways, which is what the Python guys should have done :) This crummy Sleep() implementation has some nice effects on programmers. Those who like to solve problems with lots of copy/paste code are forced to think about using proper synchronization primitives when running high resolution loops that wait for events, or their code just won't run very fast. [1] http://social.msdn.microsoft.com/forums/en-US/clr/thread/facc2b57-9a27-4049-bb32-ef093fbf4c29/ http://social.msdn.microsoft.com/forums/en-US/clr/thread/fac...

bd 16y ago
Aha, so that's probably why JavaScript timers on Windows have around 15ms accuracy: http://ejohn.org/blog/accuracy-of-javascript-time/ http://ejohn.org/blog/accuracy-of-javascript-time/
drawkbox 16y ago
True however Sleep on windows is different than sleep on posix/unix. Sleep() on windows takes ms. sleep() on nix takes seconds. Windows: VOID WINAPI Sleep( __in DWORD dwMilliseconds ); Sleep(1) is as fast as it can go which turns out to be 15-20ms. nix: #include <unistd.h> unsigned int sleep(unsigned int seconds); usleep() can be used for more granular delay on nix.
Xurinos 16y ago
When I did driver programming in Windows, it was well-known that Sleep had a resolution of 10 ms; it is based on the interrupt timer (not the high frequency timer). You could change the interrupt timer's duration, but its ticks are what guide Sleep. Not counting the effect of context switching, since you are waiting for the timer ticks, your actual times vary from 10 ms to 19.9999 ms. 15 ms is a nice way to say "on average", but I would not rely on that measure. Timers are hard to get right. Tread warily, programmers! This is one of those areas where it is good to understand some things about the computer hardware behind the software. EDIT: I should add that the high frequency timer is not a panacea either. It will work for you most of the time, but there are two circumstances that will occasionally trip you: (1) At least in Windows XP and 2000, there is a KB (I do not remember it now) that explains that for a certain small set of manufacturers, if there is a sudden spike in high load on the PCI bus, the high frequencer timer will be jumped ahead to account for the lost time during that laggy spike. This correction is not accurate. This means that if your initial timestamp is X, and you are waiting for it to be X+Y, wall clock time may be between X and X+Y, but Windows itself altered the timestamp to be X+Y+Z, and your software thinks the time has elapsed. I personally experienced this bug. (2) You actually have more than one high frequency timer -- one for each CPU on your system. Once you start playing on a system with multiple CPUs, how do you guarantee that the API is providing you a timestamp from the same timer? I remember there may have been way to choose if you dropped to assembly to make the query but that the API at the time did not support a choice. The timer starts upon power-up. If one CPU powers up after the other, you will have a timestamp skew. Some high frequency software algorithms attempt to correct for this skew. I do not know all the details to that now.

igravious 16y ago

Excuse my ignorance: what do you mean by noisy?

mustpax 16y ago
Noisy means there is a lot of variance in the actual time the process spends sleeping. When you say sleep(1) most OSes interpret that as saying, sleep as short as you can. Based on the scheduler internals, that can vary a lot.
- tptacek 16y ago
  Which OS interprets sleep(1) (ie, "sleep for 1 second") as "sleep for as short as you can"? On WinAPI, Sleep is denominated in milliseconds. On BSD, sleep(3) is a library wrapper around nanosleep(2). Linux's man pages make no mention of the magic number "1" as a "sleep 1 timeslice" shortcut; also, older Linux man pages warn that sleep(3) can be implemented in terms of alarm(1), which is used all over POSIX as an I/O timeout and would blow up the world if it alarmed in milliseconds. If you want to sleep "as short as you can", sleep for 0 seconds, or call any other system call to yield your process back to the scheduler.
  - xpaulbettsx 16y ago
    Windows also only guarantees that your process will sleep at least as long as you specify. Not that it will sleep exactly as long.
  - mustpax 16y ago
    Thanks for the correction. I was just talking about the de facto behavior I have seen on Linux and BSD for very short sleep intervals (way shorter than 1 second), not necessarily about the behavior as specified by the system call. I should have been clearer.
    - tptacek 16y ago
      I really don't think you've ever seen BSD return in milliseconds after a 1-second sleep. Respectfully, I think you're pretty much just wrong.

tptacek 16y ago

This has nothing to do with timing attacks and would do nothing to defend against them. Read 'daeken's comment below, though.