Re: "Random IV"?

The first 16 prefix bytes represent the key identifier (a GUID). They are
used to determine what key should be used for decryption. They're
particularly useful if you use multiple encryption keys per column. The
decryption builtins will automatically search for the proper key and use it
to decrypt the blob.

So, if you're doing something like

select decryptbykey(SSN) from customers

it will decrpyt all SSNs encrypted by keys that you currently have opened.

The IV is indeed prefixed to the data. IV's are not meant to be secret,
they're just used to randomize the encryption output, so that patterns in
the cleartext data are not disclosed.

Thanks

--
Laurentiu Cristofor [MSFT]
Software Design Engineer
SQL Server Engine
http://blogs.msdn.com/lcris/

This posting is provided "AS IS" with no warranties, and confers no rights.

<coles.michael@xxxxxxxxx> wrote in message
news:1151728397.102411.65150@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
I just encrypted a bunch of rows in a table. I was a little surprised
that encrypting N'A' resulted in a 44-byte result. N'AAAA' resulted in
a 52-byte result. That indicates that 8-byte padding is being used.
So the actual encrypted text of N'A' is only 8 bytes in length. What
in the world are the other 36 bytes being used for? I noticed an
interesting 'prefix' for the encrypted data:

0x0074126478AFB34BA54BA6280E2335EB010000003AE8D337EF2E5B55BABDE251B245C1FCCDB21C770073B642
0x0074126478AFB34BA54BA6280E2335EB0100000057252C84D4B6C9F3FFA40444BB7E5ADC509233F73548C7A8
0x0074126478AFB34BA54BA6280E2335EB0100000077113F30B10CC2A8FD976628C98C06C5F70E47AEEF3BE86C

It appears the first 20 bytes of every encrypted string are exactly the
same, regardless of the row, column, or data being encrypted. Further
these 20 bytes appear to be generated when the OPEN ... KEY statement
is issued. In between OPEN ... KEY statements, these first 20
characters change, but for multiple encryptions after an OPEN ... KEY
they remain the same.

These first 20 - 36 bytes wouldn't happen to be the "Random IV" would
they? One would think that storing the IV with the data would be
potentially less secure than letting the user manage their own IV...
What do you think?



.

Relevant Pages

  • Re: Securing data to a process principal
    ... encryption key first time for the user - and use it later). ... secret. ... I need the decryption to ... You MAY think that instead of a filter driver you can simply ...
    (microsoft.public.platformsdk.security)
  • Re: embedded keys - there has to be a less vulnerable approach
    ... the database would be run on top of an encrypting file system ... > The use of an asymmetrical encryption algorithm does not seem to offer ... because the encryption and decryption ... > a hostile attacker is not a member of that small knowledgeable elite. ...
    (comp.security.misc)
  • embedded keys - there has to be a less vulnerable approach
    ... the database would be run on top of an encrypting file system ... The use of an asymmetrical encryption algorithm does not seem to offer ... because the encryption and decryption ... You have a table with customer names and addresses. ...
    (comp.security.misc)
  • NTE_BAD_DATA
    ... decryption module using the self signed certificate. ... My encryption and decryption module are as follows. ... goto Exit_MyDecryptFile; ... // imported from a BLOB read in from the source file or having ...
    (microsoft.public.platformsdk.security)
  • Re: How to Facilitate and Use Data Protection on DOM (WinCE 6.0)
    ... encryption on and off, while still having the filter load. ... Decryption in my file system filter seems to work fine but the 2nd ... FS filter is NOT APPLIED to Removable USB ... Hard Disk as well as the Removable USB media. ...
    (microsoft.public.windowsce.platbuilder)