Simple-ish encryption of a String without unicode (using ASCII)
Hi Experts
I'm going to be converting a string of characters into a barcode format. These characters will be your standard ASCII characters, notably A-Z, 0-9 and perhaps a few symbols if possible.
The problem is, I want to encrypt this string, so that even if someone has a barcode scanner, what they scan will be gibberish. But when encrypting the string, I don't want the length of the string to increase too much because the barcode can only support a maximum number of characters. Add to this problem, I think my barcode format (PDF417) can only support ASCII and not unicode (I think a unicode character takes up a lot of space).
I'm NOT saying that the encrypted version should be the exact same length as the decrypted version.
I'm using Delphi, and need a simple encryption and decryption process please.
I'm going to be converting a string of characters into a barcode format. These characters will be your standard ASCII characters, notably A-Z, 0-9 and perhaps a few symbols if possible.
The problem is, I want to encrypt this string, so that even if someone has a barcode scanner, what they scan will be gibberish. But when encrypting the string, I don't want the length of the string to increase too much because the barcode can only support a maximum number of characters. Add to this problem, I think my barcode format (PDF417) can only support ASCII and not unicode (I think a unicode character takes up a lot of space).
I'm NOT saying that the encrypted version should be the exact same length as the decrypted version.
I'm using Delphi, and need a simple encryption and decryption process please.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
aikimark
ROT13 -- expanded to accomodate your alphabet size.
How about something really simple using xor?
unit Crypt32;
interface
//const
// StartKey = 981; {Start default key}
// MultKey = 12674; {Mult default key}
// AddKey = 35891; {Add default key}
var
StartKey, MultKey, AddKey : Integer;
function Encrypt(const InString:string; StartKey,MultKey,AddKey:Integer): string;
function Decrypt(const InString:string; StartKey,MultKey,AddKey:Integer): string;
implementation
{$R-}
{$Q-}
{*******************************************************
* Standard Encryption algorithm - Copied from Borland *
*******************************************************}
function Encrypt(const InString:string; StartKey,MultKey,AddKey:Integer): string;
var
I : Byte;
begin
Result := '';
for I := 1 to Length(InString) do
begin
Result := Result + CHAR(Byte(InString[I]) xor (StartKey shr 8));
StartKey := (Byte(Result[I]) + StartKey) * MultKey + AddKey;
end;
end;
{*******************************************************
* Standard Decryption algorithm - Copied from Borland *
*******************************************************}
function Decrypt(const InString:string; StartKey,MultKey,AddKey:Integer): string;
var
I : Byte;
begin
Result := '';
for I := 1 to Length(InString) do
begin
Result := Result + CHAR(Byte(InString[I]) xor (StartKey shr 8));
StartKey := (Byte(InString[I]) + StartKey) * MultKey + AddKey;
end;
end;
{$R+}
{$Q+}
end.
XOR can result in some ASCII characters that are not printable and, therefore, probably not going to be within the charactersetof the Bar Codes.
For instance, XOR '0' with '7' results in a BELL character [Hex(07)] . . . and so does 'P' XOR 'W'.
That's why I proposed an Encrypt and Decrypt string of characters that areprintable and also very probably included in the Bar Code characterset.
For instance, XOR '0' with '7' results in a BELL character [Hex(07)] . . . and so does 'P' XOR 'W'.
That's why I proposed an Encrypt and Decrypt string of characters that areprintable and also very probably included in the Bar Code characterset.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
the main issue will be the length of your string when encrypting
if you need something that nobody understands ... just use numbers in the barcode
save your texts in a table, a column text, a column id (auto number), and a column barcode number
have a routine to generate such a number
you can even make it simple for people to understand like year/month/day/indexnr
they'll think they have figured it out and say it's the date and a index
and 98% will stop hacking
that's just the start off course, as this is the index of a record in a table
no correlation to any text or string whatsoever
and you won't have any problem with string lengths
you could let the database encrypt the text for you in the text column
if you need something that nobody understands ... just use numbers in the barcode
save your texts in a table, a column text, a column id (auto number), and a column barcode number
have a routine to generate such a number
you can even make it simple for people to understand like year/month/day/indexnr
they'll think they have figured it out and say it's the date and a index
and 98% will stop hacking
that's just the start off course, as this is the index of a record in a table
no correlation to any text or string whatsoever
and you won't have any problem with string lengths
you could let the database encrypt the text for you in the text column
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
A mod 36 or mod 26 version of RC4 could preserve the length and character set without being quite as obvious as rot13
http://en.wikipedia.org/wiki/RC4#The_pseudo-random_generation_algorithm_.28PRGA.29
http://en.wikipedia.org/wiki/RC4#The_pseudo-random_generation_algorithm_.28PRGA.29
@ozo
"obvious" is the key word here. Thus my questions about the value of data being protected and the sophistication level of attackers. Obvious to us might be sufficiently obscured to the mildly curious.
"obvious" is the key word here. Thus my questions about the value of data being protected and the sophistication level of attackers. Obvious to us might be sufficiently obscured to the mildly curious.
I make no claim whether ROt13 is inadequate or RC4 is adequate for this purpose.
The key questions about the value of the data and the types of attacks it might endure are yet to be answered.
The key questions about the value of the data and the types of attacks it might endure are yet to be answered.
ASKER
I ended up using TPLockBox as recommended by SteveBay.
It isn't ideal however because it does increase my string by about 33% using Blowfish (other encryptions increased the string by even more), but I'm sure if I tinker with it some more I can get this down.
It isn't ideal however because it does increase my string by about 33% using Blowfish (other encryptions increased the string by even more), but I'm sure if I tinker with it some more I can get this down.
@rfwolf
The size increase is probably due to the encoding (Base64?) rather than the encription algorithm.
The size increase is probably due to the encoding (Base64?) rather than the encription algorithm.
ASKER
Okay I need some advice - not sure exactly what to say if I open a new question...
Basically my problem persists - if I take a string and encrypt it using TLockBox II get an inflation of about 27%.
Now somebody said this is because of Base64 -- which I don't really understand, but looking at TLockbox it looks like they all use Base64.
Basically I don't mind an inflation, but maybe of 10%, not 27%.
My INPUT data is a 171-character string. After encryption it is a 236 string.
That's inflation of 65 characters or 27.5%.
Any advice please.
Basically my problem persists - if I take a string and encrypt it using TLockBox II get an inflation of about 27%.
Now somebody said this is because of Base64 -- which I don't really understand, but looking at TLockbox it looks like they all use Base64.
Basically I don't mind an inflation, but maybe of 10%, not 27%.
My INPUT data is a 171-character string. After encryption it is a 236 string.
That's inflation of 65 characters or 27.5%.
Any advice please.
ASKER
Upon reviewing this question I can see for example ozo's comments may be helpful, but without code I simply can't try it - even pseudo-code from wikipedia.
@rfwoolf
It is possible/probable that an encrypted string will contain characters with ASCII values that can not be displayed, such as CR or LF. Sometimes an ASCII 0 character might appear in the encrypted string, causing problems if stored or passed as PChar.
Base64 encoding results in a string of alphanumeric characters, which eliminates some of the problems I identified in the preceding paragraph.
For more information, see
http://en.wikipedia.org/wiki/Base64
It is possible/probable that an encrypted string will contain characters with ASCII values that can not be displayed, such as CR or LF. Sometimes an ASCII 0 character might appear in the encrypted string, causing problems if stored or passed as PChar.
Base64 encoding results in a string of alphanumeric characters, which eliminates some of the problems I identified in the preceding paragraph.
For more information, see
http://en.wikipedia.org/wiki/Base64
@rfwoolf ,
Now that you have accepted a solution, this thread should no longer be used. You would need to open a new question, oribably rephrasing it so that it doesn't duplicate this one.
Over this weekend, I may be able to locate the substitution cypher unit that I used a while back. There was little, if any, increase in the size of the text but I would need to know the full set of characters that can be represented by your bar-code software and also the full set of characters that you would need to be able to encrypt. If you need to be able to encrypt more characters than the number available in the barcoding, then things could get somewhat complicated but that can be handled, too. (Math, as well as SQL, is your friend. ;-) However, like I said, this is not a 2 minute task. ;-)
Now that you have accepted a solution, this thread should no longer be used. You would need to open a new question, oribably rephrasing it so that it doesn't duplicate this one.
Over this weekend, I may be able to locate the substitution cypher unit that I used a while back. There was little, if any, increase in the size of the text but I would need to know the full set of characters that can be represented by your bar-code software and also the full set of characters that you would need to be able to encrypt. If you need to be able to encrypt more characters than the number available in the barcoding, then things could get somewhat complicated but that can be handled, too. (Math, as well as SQL, is your friend. ;-) However, like I said, this is not a 2 minute task. ;-)