develooper Front page | perl.perl5.porters | Postings from September 2014

Re: new long doubles option: gcc libquadmath

Thread Previous | Thread Next
From:
Josh Juran
Date:
September 21, 2014 13:20
Subject:
Re: new long doubles option: gcc libquadmath
Message ID:
20AEEA37-542E-4421-8DD3-A70C28D10F4D@gmail.com
On Sep 21, 2014, at 5:39 AM, Jarkko Hietaniemi <jhi@iki.fi> wrote:

> On Saturday-201409-20, 0:05, demerphq wrote:
>>    I know you're being facetious, and crypto uses integer math so we're
> 
> Moi?  Facetious?  I don't even know that word.

<http://www.youtube.com/watch?v=-fNvi6xG-5Y>

>>    not talking about leaking private key material, but as a general
>>    principle, transporting garbage should be avoided.  It was bad when
>>    Microsoft Word bumped a document file's logical EOF to match its
>>    physical EOF (thus carrying around a partial block of who-knows-what
>>    prior data, which very well could have included your credit card
>>    number), and it's bad now. Any unused bits in the in-memory format
>>    should be zeroed before transmission or storage.
>> 
>> 
>> I agree. Sereal will zero the extra bytes. (Cant remember this second if
>> that is going to be the next release, or the current one.)
> 
> As does Perl's pack/unpack code for long double.
> ... checking ...
> Wait, I can see explicit zeroing only in the pack() case (search for
> "unused bits" in pp_pack.c.  Will investigate whether the unpack()
> does it somehow more sneakily.

Another issue beyond leaking possibly sensitive information is that a non-normalizing implementation will produce equivalent values that are not bitwise-equal, which could be a problem if a program attempted to compare serialized values directly.  (And it seems that any correctness issue is a potential security issue as well.)

Josh



Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About