dulux_encrypt in dFLUP_Q

Hi all,

OK, my ego's getting to me.  If anyone (apart from Jan - thanks Jan) has 
tried out my Encryption routine released in the latest library, I'd love to 
know what you think, both good and bad, and any suggestions you might have.

Cheers

dulux
aka Matthew James BLACK 

Name George Walker Bush which has 18 characters  encrypted to
A5C707A6028C732D00058D6DE1BC4B31 for 32 characters !
Social Security # 123-45-6789 has 11 characters encrypted to
C5E11B162443FFE1D96E06EC726BC8E2 for 32 characters !

What determines the amount of storage space required for an encypted field ?

Matthew,

I have used it and it works fine, EXCEPT when the plain text is less than 4
characters. It produces a an empty cypher text string.

Is this working as designed?

regards, andrew

Dulux wrote:
> Hi all,
> 
> OK, my ego's getting to me.  If anyone (apart from Jan - thanks Jan) has 
> tried out my Encryption routine released in the latest library, I'd love to

> know what you think, both good and bad, and any suggestions you might
have.
> 
> Cheers
> 
> dulux
> aka Matthew James BLACK 
> 

Read the custom class comments on how it works. The author warns the cypher text
will be longer and there is an explanation why.

Dan Cook wrote:
> Name George Walker Bush which has 18 characters  encrypted to
A5C707A6028C732D00058D6DE1BC4B31 for 32 characters !
> Social Security # 123-45-6789 has 11 characters encrypted to
C5E11B162443FFE1D96E06EC726BC8E2 for 32 characters !
> 
> What determines the amount of storage space required for an encypted field
?
> 

Matthew is disconnected from the newsgroups at the moment and asked me to post
the following reply to my post.

regards, andrew

Hi Andrew,
 
Thanks for sending me this - I'm offline as far as the newsgroups are concerned
at the moment.  Would you mind forwarding this reply to the group(s) - thanks.
 
Yes, this is as designed - the smallest Block of Plaintext that this
implementation of Rijindael (the algorithm) can handle is 4 "words"
each 32 bits long (4 characters each or 16 characters).  The way the code
divides the Plaintext into "words" assumes a minimum of four
characters.  The assumption behind this is that "everyone" is using
passwords/encryptions/whatever that are at least 6+ characters long.  The
algorithm pads the the plaintext to the next 32-bit word boundary (ie the
plaintext is padded to a multiple of 16 characters) - this is as the published
Rinjindael Algorithm.  Incidentally, the Key is also padded to the next
word-group boundary, as per the algorithm.  The way Rijindael does its job means
that this is not an issue cryptographically - you can use a Key of ""
and it will still be cryptographically secure.
 
The AES standard based on Rijindael specifies a fixed Block-size of four
"words" each 32-bits long (128-bits), with a 128-bit, 192-bit, or
265-bit Key - my version allows blocks or Keys of 128-bit, 160-bit, 192-bit,
224-bit, or 256-bit (mainly because I could when I was writing the code),
defaulting to 128-bits for both.  If you use a larger Block or Key-size, the
Plaintext or Key are padded to the next Block-size or Key-size boundary.
 
Bottom line: because the code requires the use of a modular function
(Plaintext%4, to be specific), any plaintext less than 4 characters will result
in a zero-length input-string into the cryptography, resulting in an empty
Cyphertext.  Could I have checked for that - probably, but I never considered
anyone using it to encrypt a string less than 4 characters long - well, I
considered it and assumed that no-one would try, thus saving myself some coding
and computational time.
 
The solution: I'll rewrite that part of the code (when I get a moment to scratch
myself).
 
The workaround: you manually pad any Plaintext with characters (I suggest you
don't use Spaces)  until your plaintext is at least 4 characters long - the code
will then tack care of the rest.  When you decrypt, strip those extra characters
out - so you should probably pad with a character you won't normally get in the
Plaintext (eg "~")
 
Any other feedback, or further explanations, just ask
 
Cheers
 
matt


Andrew Shimmin wrote:
> Matthew,
> 
> I have used it and it works fine, EXCEPT when the plain text is less 
> than 4 characters. It produces a an empty cypher text string.
> 
> Is this working as designed?
> 
> regards, andrew
> 
> Dulux wrote:
>> Hi all,
>>
>> OK, my ego's getting to me.  If anyone (apart from Jan - thanks Jan) 
>> has tried out my Encryption routine released in the latest library, 
>> I'd love to know what you think, both good and bad, and any 
>> suggestions you might have.
>>
>> Cheers
>>
>> dulux
>> aka Matthew James BLACK