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,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 10.66.252.198 with SMTP id zu6mr2335957pac.25.1398407181984; Thu, 24 Apr 2014 23:26:21 -0700 (PDT) Path: border1.nntp.dca.giganews.com!nntp.giganews.com!l13no10613981iga.0!news-out.google.com!dz10ni21107qab.1!nntp.google.com!peer01.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!post01.iad.highwinds-media.com!fx04.iad.POSTED!not-for-mail From: Shark8 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:31.0) Gecko/20100101 Thunderbird/31.0a1 MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Side-channel Attacks (Time) References: <2wl6v.162063$kp1.28371@fx14.iad> <87lhuuuha3.fsf@kuiper.lan.informatimago.com> <877g6eufcj.fsf@kuiper.lan.informatimago.com> In-Reply-To: <877g6eufcj.fsf@kuiper.lan.informatimago.com> Message-ID: X-Complaints-To: abuse@teranews.com NNTP-Posting-Date: Fri, 25 Apr 2014 06:26:21 UTC Organization: TeraNews.com Date: Fri, 25 Apr 2014 00:26:15 -0600 X-Received-Bytes: 2709 X-Received-Body-CRC: 2941092631 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Original-Bytes: 2728 Xref: number.nntp.dca.giganews.com comp.lang.ada:186085 Date: 2014-04-25T00:26:15-06:00 List-Id: On 24-Apr-14 23:51, Pascal J. Bourguignon wrote: > 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. No, that's wrong. If your processing time is 1 ms for 'fail' but response is padded to 10 ms and your processing time for 'success' is 10 ms then trafficwise there is no difference: both are 10 ms form reception-to-response. > 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. Um, all of these presuppose (a) compromised physical security, and/or (b) compromised 'process security' [that is, an already-compromised system] -- I contend both of these are outside the scope of a SW library.