Por ejemplo, ¿funcionaría este código (pseudo)?
let t = timeRightNow()
let message = stuffWhoseTimingCantBeLeaked()
waitUntilTime(t+1 second)
send message
¿O similar? De ese modo, la hora en que se envía el mensaje no depende de la sincronización de stuffWhoseTimingCantBeLeaked() .
¿Un atacante aún podría determinar cuánto tardó en ejecutarse stuffWhoseTimingCantBeLeaked() ?
Siempre que t + s sea suficiente para cubrir los retrasos en las respuestas introducidas por un ataque estilo DDoS, donde s es el número de segundos.
Es decir, golpear a un oyente del servicio que llama a lo anterior para alentar a stuffWhoseTimingCantBeLeaked() a tomar más tiempo que s podría revelar al atacante cuánto tiempo, en promedio, stuffWhoseTimingCantBeLeaked() tarda en ejecutar, una vez que t + s barrera está rota.
Para mitigar esto, puede enmascarar este tiempo adicional detectando cuando su función toma más tiempo:
let t = timeRightNow()
let s = 1
let waitTime = t + s
let message = stuffWhoseTimingCantBeLeaked()
let executeTime = timeRightNow() - t
if timeRightNow() > waitTime
waitUntilTime(timeRightNow() + executeTime * csprng(2,1)) # Random wait of between 1 and 2 times the original execution time (integer)
else
waitUntilTime(waitTime)
send message
Tenga en cuenta que, con con suficientes solicitudes puede ser posible obtener un promedio que se iguale, perdiendo el tiempo necesario para ejecutar stuffWhoseTimingCantBeLeaked() .
Con valores más altos de s , el riesgo puede reducirse aún más, a expensas del rendimiento. También puede introducir la detección de si su servicio web se solicita repetidamente a un determinado usuario o dirección IP y luego limitar la velocidad de la conexión.
Lea otras preguntas en las etiquetas web-service timing-attack