[131786] in cryptography@c2.net mail archive
Re: Decimal encryption
daemon@ATHENA.MIT.EDU (Greg Rose)
Wed Aug 27 16:12:38 2008
Date: Wed, 27 Aug 2008 09:34:15 -0700
From: Greg Rose <ggr@qualcomm.com>
To: =?ISO-8859-15?Q?Philipp_G=FChring?= <pg@futureware.at>
CC: "cryptography@metzdowd.com" <cryptography@metzdowd.com>
In-Reply-To: <48B56D48.3090109@futureware.at>
Philipp G=FChring wrote:
> Hi,
G'day Philipp,
> I am searching for symmetric encryption algorithms for decimal strings.=
>=20
> Let's say we have various 40-digit decimal numbers:
> 2349823966232362361233845734628834823823
> 3250920019325023523623692235235728239462
> 0198230198519248209721383748374928601923
>=20
> As far as I calculated, a decimal has the equivalent of about 3,3219
> bits, so with 40 digits, we have about 132,877 bits.
>=20
> Now I would like to encrypt those numbers in a way that the result is a=
> decimal number again (that's one of the basic rules of symmetric
> encryption algorithms as far as I remember).
>=20
> Since the 132,877 bits is similar to 128 bit encryption (like eg. AES),=
> I would like to use an algorithm with a somewhat comparable strength to=
AES.
> But the problem is that I have 132,877 bits, not 128 bits. And I can't
> cut it off or enhance it, since the result has to be a 40 digit decimal=
> number again.
>=20
> Does anyone know a an algorithm that has reasonable strength and is abl=
e
> to operate on non-binary data? Preferrably on any chosen number-base?
There is a fairly standard technique for handling things like this.
1. encode your number N into a 133-bit string S
2. encrypt S with your favourite 133-bit block cipher (see below)
3. decode S to a number N'
4. if N' >=3D 10^40, goto 2 (that is, re-encrypt until it is in range)
5. N' is your answer.
This is uniquely invertible, although a little slow (since on average it =
will take 8.9% or so more encryptions because of the inner loop, and=20
some side-channel information leaks when it does the extra encryptions.=20
Decryption is exactly the same operation except step 2 uses decryption=20
mode of the block cipher.
So, you don't have a 133-bit block cipher lying around? No worries, I'll =
sell you one ;-). Actually that is easy too. Take a trustworthy 128-bit=20
block cipher like AES. To encrypt, do:
1. Encrypt the first 128 bits (ECB mode)
2. Encrypt the last 128 bits (also ECB mode).
To decrypt, do decryptions in the reverse order, obviously. It's easy to =
see that this is a secure permutation if AES itself is, depending on=20
your definition of secure; if you add a third step, to re-encrypt the=20
first 128 bits, it is truly secure. (Without the third step, tweaking a=20
bit in the first 5 bits will often leave the last 5 unchanged on=20
decryption, which is clearly a distinguishing attack; the third=20
encryption makes it an all-or-nothing transform.)
I believe the above gives you a secure enough block cipher on 40 digit=20
strings, and if you only ever encrypt single chunks, ECB mode should be=20
fine... of course that depends on the real threat analysis of your=20
system. It does about 2.19 AES encryptions per 40 digits, should be fast =
enough.
hope that helps,
Greg.
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
