# Re: Decimal encryption

```Philipp Gühring wote:

> I am searching for symmetric encryption algorithms for decimal strings.
>
> Let's say we have various 40-digit decimal numbers:
> 2349823966232362361233845734628834823823
> 3250920019325023523623692235235728239462
> 0198230198519248209721383748374928601923
>
> 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.```
```
English readers normally use "." as the decimal point - you had me confused
for a few seconds and maybe it wasn't only me.

Regardless of the calculated bit-equivalent you aren't storing these strings
in 132.877 bits - but possibly 40*8 bits, 40*4 bits or in some other way.

> 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).

I don't think that's a feature of the encryption as such.

> 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.

This sounds like possible confusion over block length and key size.  Then
you get involved in padding and storage of a slightly larger ciphertext.

> Does anyone know a an algorithm that has reasonable strength and is able
> to operate on non-binary data? Preferrably on any chosen number-base?

It sounds as if you want a stream cipher arrangement that you could make
out of a normal binary stream cipher by:
read a byte of the keystream
if > 9 reject it and take the next one (aiming for uniform distribution)
if the value is [0-9] add it to the current plaintext digit mod 10

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
```