From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 Path: border2.nntp.dca3.giganews.com!backlog4.nntp.dca3.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!usenet.blueworldhosting.com!feeder01.blueworldhosting.com!feeder.erje.net!eu.feeder.erje.net!news-1.dfn.de!news.dfn.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: "Pascal J. Bourguignon" Newsgroups: comp.lang.ada Subject: Re: Side-channel Attacks (Time) Date: Fri, 25 Apr 2014 07:51:08 +0200 Organization: Informatimago Message-ID: <877g6eufcj.fsf@kuiper.lan.informatimago.com> References: <2wl6v.162063$kp1.28371@fx14.iad> <87lhuuuha3.fsf@kuiper.lan.informatimago.com> Mime-Version: 1.0 Content-Type: text/plain X-Trace: individual.net AoXkr1xFwhywCtF2kn7m8QgkMHtQMbzDk4SXgSmFRmzfuFdafj Cancel-Lock: sha1:NmVmMDM2MzRjZDAwYTk2ZjRhZTYxZjkyMTBiZDU2MjcxNzlmODQwZQ== sha1:Sqjh07WUZkOkyB7x3Aad6HQ8sZU= Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwAQMAAABtzGvEAAAABlBMVEUAAAD///+l2Z/dAAAA oElEQVR4nK3OsRHCMAwF0O8YQufUNIQRGIAja9CxSA55AxZgFO4coMgYrEDDQZWPIlNAjwq9 033pbOBPtbXuB6PKNBn5gZkhGa86Z4x2wE67O+06WxGD/HCOGR0deY3f9Ijwwt7rNGNf6Oac l/GuZTF1wFGKiYYHKSFAkjIo1b6sCYS1sVmFhhhahKQssRjRT90ITWUk6vvK3RsPGs+M1RuR mV+hO/VvFAAAAABJRU5ErkJggg== X-Accept-Language: fr, es, en User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) X-Original-Bytes: 3098 Xref: number.nntp.dca.giganews.com comp.lang.ada:186084 Date: 2014-04-25T07:51:08+02:00 List-Id: Shark8 writes: > On 24-Apr-14 23:09, Pascal J. Bourguignon wrote: >> Shark8 writes: >> >>> Considering the needs for a secure, verified security library [to >>> replace OpenSSL] I was wondering about using the TASK construct in >>> conjunction with DELAY UNTIL /OP_UPPERBOUND/* would be an acceptable >>> countermeasure. >> >> It could help. >> >> Choosing an algorithm without branches, and with fixed count loops would >> be better. > > Hm, there's a thought. > I rather do like the DELAY UNTIL solution as it concisely states the > intention as a timing-attack countermeasure. (Though I've got pretty > much no experience in real-time systems, so I can't say if it's > actually appropriate.) The point is that it's too easy to detect the actual processing time, vs. the sleeping time waiting for the delay. For example, your electric counter could be monitored by the enemy, and would let him deduce the processing time from the instaneous power consumed by your computer. Or for a purely software attack, another process can easily detect when more processing time becomes available because other tasks are sleeping. Even at small scale, on multicores, you could easily detect the difference in RAM access contention. >> But even in that case, if physical access to the processor is available, >> physical side effects can be detected, and from them information about >> the data can be deduced. > > I think physical security is well beyond the scope of a software library. > >> Of course, it's as always a matter of risk and graduated counter-measures. > > Certainly. -- __Pascal Bourguignon__ http://www.informatimago.com/ "Le mercure monte ? C'est le moment d'acheter !"