Re: [sqlite] Encrypting data stored in database

[Joey Blankenship]

No argument here.  We're targeting x86 and xScale architectures so we're 
able to reference DWORD objects on non-DWORD boundaries.  I never really 
meant to distribute this code so we only tried to get it working for our 
purposes.  I just hope someone can get some use from it.

Joey.
At 04:11 PM 9/10/2004, you wrote:
Joey Blankenship <[EMAIL PROTECTED]> writes:
>   if( !ReadFile(id->h, pBuf, amt, &got, 0) ){
>     got = 0;
>   }
>
>   // PPD - XOR the buffer with a pattern so the disk file contents are not
> in plain text
>   for (i = 0; i < got/4; i++)
>   {
>     *((DWORD *)((DWORD *)pBuf + i)) = (*((DWORD *)((DWORD *)pBuf +
> i)))^0xA5A5A5A5;
>   }
DANGER, DANGER, Will Robinson!  If pBuf is not pointing to a boundary that is
legal on the hardware architecture for a DWORD pointer, this will crash the
program.  It may work, either because the hardware architecture allows for
dereferencing DWORD pointers at any address, or because pBuf is always on such
a boundary, but may fail later if other changes are later made.
>   // XOR the buffer with a pattern - any leftover bytes
>   for (i = 0; i < got%4; i++)
>   {
>     *((BYTE *)((BYTE *)pBuf + i)) = (*((BYTE *)((BYTE *)pBuf + i)))^0xA5;
>   }
I don't believe that this is doing what you expect.  The above DWORD section
did not update pBuf, so this is manipulating the *first* 0-3 bytes, not the
0-3 bytes at the end, i.e. the leftover bytes, as you desire.
Although potentially minimally slower, I'd just do a byte-by-by XOR.  The fact
that you're doing the pointer addition (twice) each iteration is probably
slower anyway (although optimizers are mighty good these days).
Here's an alternative solution that replaces both sets of loops:
{
  char *          p;
  char *          pend;
  for (p = pBuf, pEnd = pBuf + got; p < pEnd; )
  {
    *p++ ^= 0xA5;
  }
}
Cheers,
Derrell