Re: Storing Encrypted decimals as decimals
From: Andrew Swallow (am.swallow_at_eatspam.btinternet.com)
Date: 02/24/04
- Next message: Bartosz Zoltak: "Re: A variation of RC4"
- Previous message: Sisyphus: "Re: anybody interested in math on Big Numbers"
- In reply to: Charles Shopsin: "Storing Encrypted decimals as decimals"
- Next in thread: John Savard: "Re: Storing Encrypted decimals as decimals"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Tue, 24 Feb 2004 01:14:37 +0000 (UTC)
"Charles Shopsin" <charlie@inane.org> wrote in message
news:4cfe9dbb.0402231602.78ec3ce2@posting.google.com...
> I recently got slapped with a new requirement for a project I'm
> working on that certain decimal fields (meaning System.Decimal type in
> MS .net, I've included a description of the type below) need to be
> stored in an encrypted form in our database. For a lot of reasons it
> would be really nice not to have to change all of the decimal fields
> in our tables, stored procs, data-tier, etc to use byte arrays or
> strings. So...
>
> Does anyone know of a reasonably secure way to encrypt decimals so the
> encrypted value can be placed in a decimal?
>
> The stumbling blocks I've found are
> a) that most of the algorithms require minimum block sizes (usually 16
> bytes)
> b) the resulting bytes most likely will not correspond to a valid
> decimal value (especially since decimal's binary storage format has
> several bits that are always zero).
> c) in addition, since a significant fraction of the values will be
> either 0 or 1, if they all have the same key they will all have the
> same cypher-text (cypher-decimal) value, providing an easy starting
> place for someone who wants to crack the encryption.
>
> All of these decimals are stored in rows with unique guids, so I can
> use that in the process.
>
> I was thinking of something along the lines of:
> * encrypt the row guid using the client's AES key.
> * perform some sort of two-way numeric transformation on the decimal
> using the encrypted value of the guid (such as XOR).
> * when I want to decrypt, just encrypt the guid again, and run the
> numeric transform backwards.
>
> Any tips?
>
> Thanks,
> Charles
>
> -------------- Description of System.Decimal-------------
> The Decimal value type represents decimal numbers ranging from
> positive 79,228,162,514,264,337,593,543,950,335 to negative
> 79,228,162,514,264,337,593,543,950,335. The Decimal value type is
> appropriate for financial calculations requiring large numbers of
> significant integral and fractional digits and no round-off errors.
>
> A decimal number is a signed, fixed-point value consisting of an
> integral part and an optional fractional part. The integral and
> fractional parts consist of a series of digits that range from zero to
> nine (0 to 9), separated by a decimal point symbol.
>
> The binary representation of a Decimal number consists of a 1-bit
> sign, a 96-bit integer number, and a scaling factor used to divide the
> integer number and specify what portion of it is a decimal fraction.
> The scaling factor is implicitly the number 10, raised to an exponent
> ranging from 0 to 28.
>
> The return value is a four-element long array of 32-bit signed
> integers.
>
> The first, second, and third elements of the returned array contain
> the low, middle, and high 32 bits of the 96-bit integer number.
>
> The fourth element of the returned array contains the scale factor and
> sign. It consists of the following parts:
>
> Bits 0 to 15, the lower word, are unused and must be zero.
>
> Bits 16 to 23 must contain an exponent between 0 and 28, that
> indicates the power of 10 to divide the integer number.
>
> Bits 24 to 30 are unused and must be zero.
>
> Bit 31 contains the sign; 0 meaning positive, and 1 meaning negative.
>
> Note that the bit representation differentiates between negative and
> positive zero. These values are treated as being equal in all
> operations.
1. Except for Key fields the internal format of a field and its user
program implementation do not have to be the same. The
encryption program can convert them.
2. No user program should have access to the raw database. All
access needs to go through the encryption/decryption software.
3. The back up program can access the raw database data but
since that does not have a needed to know the field types it
can handle encrypted fields as binary data.
4. The encryption/software can have interface routines called
READ, WRITE, UPDATE and FIND etc. The user programs
call these routines rather than the data base routines with
similar names and parameters.
5. You may need to call a routine to start both the encryption
software and the database.
Andrew Swallow
- Next message: Bartosz Zoltak: "Re: A variation of RC4"
- Previous message: Sisyphus: "Re: anybody interested in math on Big Numbers"
- In reply to: Charles Shopsin: "Storing Encrypted decimals as decimals"
- Next in thread: John Savard: "Re: Storing Encrypted decimals as decimals"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
