Re: Datatype-preserving encryption
- From: Mike Amling <nospam@xxxxxxxxxx>
- Date: Fri, 07 Apr 2006 18:58:19 GMT
David Wagner wrote:
Dilbertarian wrote:
Is there any de facto standard for datatype-preserving encryption,
or at least some perspective ?
The purpose is that the output of the encryption process consists
of bytes belonging to the *same* alphabet as the clear data.
How about just translating the input alphabet to bits, encrypting the
bits, then translating the encrypted bits to the desired output alphabet?
The translations can be unkeyed and do not need to be secure. That should
be pretty straightforward, I think.
It's not quite that simple. If the data-->bitstring transformation is not onto, the encryption may produce a bitstring that does not correspond to any "data".
This pops up several times a year in comp.lang.java.security, where someone takes byte[] aa=someString.getBytes(), applies byte[] bb=encrypt(aa), then does String cc=new String(bb) and wonders why cc.getBytes() has different content from bb. The Java documentation now points out what has always been true, that new String(bb) is not defined if the byte[] is not a valid encoding of a String using the default (or specified) encoding system.
--Mike Amling
.
- Follow-Ups:
- Re: Datatype-preserving encryption
- From: Phil Carmody
- Re: Datatype-preserving encryption
- From: David Wagner
- Re: Datatype-preserving encryption
- References:
- Datatype-preserving encryption
- From: Dilbertarian
- Re: Datatype-preserving encryption
- From: David Wagner
- Datatype-preserving encryption
- Prev by Date: Re: CTR and disk sector encryption
- Next by Date: Re: Datatype-preserving encryption
- Previous by thread: Re: Datatype-preserving encryption
- Next by thread: Re: Datatype-preserving encryption
- Index(es):
Relevant Pages
|