Simple-ish encryption of a String without unicode (using ASCII)

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.

                                              

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
25:
26:
27:
28:
29:
30:
31:
32:
33:
34:
35:
36:
37:
38:
39:
40:
41:
42:
43:
44:
45:
46:
47:
48:
49:
50:

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.

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

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

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

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.

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.

@rfwolf

The size increase is probably due to the encoding (Base64?) rather than the encription algorithm.

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.

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