1. Blowfish.e versus decimal points
I'm thinking this is a bug, but I'm willing to be convinced otherwise.
InputSequence =
{{"Name",{1.234,1.345,1.456}},{"Name2",{1.2234,1.2345,1.2456}}}
After Encrypting and Decrypting (using the Blowfish_Encipher_Sequence and
Blowfish_Decipher_Sequence methods), the sequence is:
OutputSequence =
{{"Name",{1,1,1}},{"Name2",{1,1,1}}}
If I try
InputSequence =
{{"Name",{1234,1345,1456}},{"Name2",{12234,12345,12456}}}
Then (it works) with:
OutputSequence =
{{"Name",{1234,1345,1456}},{"Name2",{12234,12345,12456}}}
Obviously, I can work with whole numbers and divide as necessary, but I'm
wondering if anybody has run into this and knows the solution/work around.
I'm using blowfish.zip from the archive, which includes this line in
documentation file:
Updated 28/1 2004
Along with Euphoria 3.1.1 and Win32Lib (the latest version). I'm generating the
program in Enhanced IDE v1.0.3
Other things I've tried:
1) Different encryption methods (0 or 1) - neither works
2) Direct encryption to files (Set_Encrypt(ENC_ON))
Thanks
Mike
2. Re: Blowfish.e versus decimal points
Mike777 wrote:
>
> I'm thinking this is a bug, but I'm willing to be convinced otherwise.
>
> (snip)
>
> Obviously, I can work with whole numbers and divide as necessary, but I'm
> wondering
> if anybody has run into this and knows the solution/work around.
>
> I'm using blowfish.zip from the archive, which includes this line in
> documentation
> file:
>
> Updated 28/1 2004
I too have been using blowfish.e for a while now, and I never noticed this
issue. It's probably because I only encode text strings, and not numerical data.
I found that the issue is not with blowfish.e (by Alexander Toresson), but with
binary.e (by Jordah Ferguson). Here is the affected code:
function Atom2Seq(atom x)
Sign = ((x>0)-(x<0))
x *= Sign
if x = NULL then
TYPE = NULL
return {}
elsif x <= #FF then
TYPE = CHAR*Sign
return {x}
elsif x <= #FFFF then
TYPE = WORD*Sign
return {and_bits(x,#FF),floor(x/#100)}
elsif x <= #1000000 then
TYPE = TRI*Sign
return {and_bits(x,#FF),and_bits(floor(x/#100),#FF),floor(x/#10000)}
elsif x <= #FFFFFFFF then
TYPE = LONG*Sign
poke4(CONVMEM,x)
return peek({CONVMEM,LONG})
elsif x <= 3.4E38 then
TYPE = FLOAT32
return machine_func(48,x)
elsif x <= 1.7E308 then
TYPE = DOUBLE
return machine_func(46,x)
end if
end function
As you can see, anything that is less than #FF (255), which includes 1.234, gets
turned into a "CHAR" type, which assumes the value is an integer, and not an
atom. The solution here is to simply re-arrange the code so it handles atoms
separately from integers:
function Atom2Seq(atom x)
Sign = ((x>0)-(x<0))
x *= Sign
if x = NULL then
TYPE = NULL
return {}
elsif integer(x) then
if x <= #FF then
TYPE = CHAR*Sign
return {x}
elsif x <= #FFFF then
TYPE = WORD*Sign
return {and_bits(x,#FF),floor(x/#100)}
elsif x <= #1000000 then
TYPE = TRI*Sign
return {and_bits(x,#FF),and_bits(floor(x/#100),#FF),floor(x/#10000)}
elsif x <= #FFFFFFFF then
TYPE = LONG*Sign
poke4(CONVMEM,x)
return peek({CONVMEM,LONG})
end if
elsif x <= 3.4E38 then
TYPE = FLOAT32
return machine_func(48,x)
elsif x <= 1.7E308 then
TYPE = DOUBLE
return machine_func(46,x)
end if
end function
In testing, the new code handles atom values "correctly" as demonstrated here:
Before: {4.567,5.678,6.789}
After: {4.566999912,5.677999973,6.789000034}
As you can see, the conversion to/from floating point values back to atoms kinda
skews the decimal a bit. This is fairly common when doing such conversions.
-Greg
3. Re: Blowfish.e versus decimal points
- Posted by Mike777 <anon4321 at g?ail?com>
Jan 15, 2008
-
Last edited Jan 16, 2008
Greg Haberek wrote:
>
> Mike777 wrote:
> >
> > I'm thinking this is a bug, but I'm willing to be convinced otherwise.
> >
> > (snip)
> >
> > Obviously, I can work with whole numbers and divide as necessary, but I'm
> > wondering
> > if anybody has run into this and knows the solution/work around.
> >
> > I'm using blowfish.zip from the archive, which includes this line in
> > documentation
> > file:
> >
> > Updated 28/1 2004
>
>
> I too have been using blowfish.e for a while now, and I never noticed this
> issue.
> It's probably because I only encode text strings, and not numerical data. I
> found that the issue is not with blowfish.e (by Alexander Toresson), but with
> binary.e (by Jordah Ferguson). Here is the affected code:
<snip>
> Before: {4.567,5.678,6.789}
> After: {4.566999912,5.677999973,6.789000034}
>
> As you can see, the conversion to/from floating point values back to atoms
> kinda
> skews the decimal a bit. This is fairly common when doing such conversions.
Thanks, Greg. That allowed me to get by that issue.
On to bigger and better...
Have you had any problem with consistency? I've been able to encrypt a
relatively simple sequence and then I change a few bytes of the sequence being
encrypted and I get a "slice ends past end of sequence (xxx) yyy" error at
blowfish.e:308, which is: sel = bytes[a..a+7] when decrypting it.
I don't know whether this issue is related to the prior one (I don't think so).
Here is a sample of the type of sequence that will work (with a given key):
{{"Oct, 2005",877,888,817,802,838,829,886,840},{"Oct,
2006",900,888,817,802,838,829,886,840}}
Then, if I change the 900 to 432, I get the error:
{{"Oct, 2005",877,888,817,802,838,829,886,840},{"Oct,
2006",432,888,817,802,838,829,886,840}}
There is no pattern I can discern (although I'm sure there is one). I can have
a perfectly acceptable sequence and then I change the init key or change a few
bytes and it won't decrypt. I never seem to have problems encrypting. It is
always coming back the other direction that creates the problem.
Thanks
Mike
4. Re: Blowfish.e versus decimal points
- Posted by Greg Haberek <ghaberek at ?mail.co?>
Jan 15, 2008
-
Last edited Jan 16, 2008
> On to bigger and better...
>
> Have you had any problem with consistency? I've been able to encrypt a
> relatively
> simple sequence and then I change a few bytes of the sequence being encrypted
> and I get a "slice ends past end of sequence (xxx) yyy" error at
> blowfish.e:308,
> which is: sel = bytes[a..a+7] when decrypting it.
>
> I don't know whether this issue is related to the prior one (I don't think
> so).
>
> Here is a sample of the type of sequence that will work (with a given key):
>
> {{"Oct, 2005",877,888,817,802,838,829,886,840},{"Oct,
> 2006",900,888,817,802,838,829,886,840}}
>
> Then, if I change the 900 to 432, I get the error:
>
> {{"Oct, 2005",877,888,817,802,838,829,886,840},{"Oct,
> 2006",432,888,817,802,838,829,886,840}}
>
> There is no pattern I can discern (although I'm sure there is one). I can
> have
> a perfectly acceptable sequence and then I change the init key or change a
> few bytes and it won't decrypt. I never seem to have problems encrypting.
> It is always coming back the other direction that creates the problem.
I ran into the same issue, too. I think it was because I was reading/writing
files in text mode. You have to open your files as "rb" or "wb" because the
encrypted data is binary, not text. That should fix your issue. Though I had that
issue quite a while ago, and never made note of how to fix it. So I could be
wrong...
-Greg
P.S. I found a couple other bugs in blowfish.e, in the wrappers for the file
routines:
-- line 523, change this:
else
call_proc(oldprint, {fn, st, x})
end if
-- to this:
else
call_proc(oldprintf, {fn, st, x})
end if
-- at line 535, change this:
integer found
sequence line, st
found = find(fn, filefns)
-- to this:
integer found
sequence line
object st
found = find(fn, filefns)
5. Re: Blowfish.e versus decimal points
- Posted by Mike777 <anon4321 at ?mail?com>
Jan 15, 2008
-
Last edited Jan 16, 2008
Greg Haberek wrote:
> >
> > There is no pattern I can discern (although I'm sure there is one). I can
> > have
> > a perfectly acceptable sequence and then I change the init key or change a
> > few bytes and it won't decrypt. I never seem to have problems encrypting.
> > It is always coming back the other direction that creates the problem.
>
> I ran into the same issue, too. I think it was because I was reading/writing
> files in text mode. You have to open your files as "rb" or "wb" because the
> encrypted data is binary, not text. That should fix your issue. Though I had
> that issue quite a while ago, and never made note of how to fix it. So I could
> be wrong...
You are not wrong. I was writing everything with binary, but I was reading one
file with text. I thought it wouldn't matter because I had used a text editor
that allows long lines and all of the data (the entire sequence) was on one line.
Or so I thought.
> P.S. I found a couple other bugs in blowfish.e, in the wrappers for the file
> routines:
>
> }}}
<eucode>
> -- line 523, change this:
> else
> call_proc(oldprint, {fn, st, x})
> end if
> -- to this:
> else
> call_proc(oldprintf, {fn, st, x})
> end if
>
> -- at line 535, change this:
> integer found
> sequence line, st
> found = find(fn, filefns)
> -- to this:
> integer found
> sequence line
> object st
> found = find(fn, filefns)
> </eucode>
{{{
Thanks. I'll put this on my list of things to update on my version.
Mike
