Re: Encryption ??

Klas Engwall wrote:
Bill,

I would like to jump directly to the bottom line if I may: How the
calling Clipper application is affected by the string handling in the
TEA implementation.

Klas,

I think the bottom line is to use only the encode and decode function that are published and none of dwyer's work. He changed the whiles to for, so he didn't use the published work anyway. His TEA_encrypt and TEA_decrypt was done so that he would have a complete program to encrypt and decrypt data longer than 8-bytes. The appending unencrypted bytes at the end must have been a design decision. He could have correctly block the last chunk even easier that his fix. The only reasonable assumption is he needed the data to fit in exactly the same space after encryption and it wasn't worth the effort to hide a few bytes.

If his calling convention was fixed we would have clipper calling a wrapper through the expand.api, calling what's essentially a routine to handle streams longer than 64-bits that calls the real algorithm -- a 4-step process.

I think you have already stated that the blocking and padding should be done in clipper and I agree. That would simplify the 4-step calling sequence to 3. Clipper blocking the data stream in 8-byte chunks, accessing the decode/encode via extend.api and padding the last chunk to 8-bytes if necessary. Any speed that c would provide in the padding and blocking would probably be picked up by eliminating a c-routine.

I don't seem any real problem in the string handling even though it has the "potential" for buffer overflow. You have to misuse the encrypted data for that to happen using functions that depend upon the '\0' being at the end of a string. Since either the encrypted or decrypted data could be binary with embedded '\0's in the stream you have the possibility of losing or gaining data; both bad. Gaining bytes in c is usually worse because you can get buffer over run, if you try. Ask Microsoft if anyone would ever try to exploit a potential buffer over run. If think they would say -- never.

Programs exists that tests c-programs for these kinds of traps. Unfortunately, I don't have one.
.

Relevant Pages

  • Re: Z/os mainframe encryption
    ... It seems I need to obtain a key identifier by calling CSNBKGN and also specify an initialization vector to encrypt. ... For IBM-MAIN subscribe / signoff / archive access instructions, ... send email to listserv@xxxxxxxxxxx with the message: GET IBM-MAIN INFO ... After the ICSF CSFKRR service reads the key from the CKDS database it returns a token value which is used by the decrypt and encrypt routines. ...
    (bit.listserv.ibm-main)
  • Re: pdf writer document encryption
    ... >> I've tried and tried but can't seem to figure out how to encrypt a pdf ... >> document with pdf writer. ... Just calling the encrypt method throws an ...
    (comp.lang.ruby)
  • Re: C# System.String Memory Usage
    ... calling it manually will hardly do anything useful ... on a single server. ... have lots of string handling where placing a GC.Collect in the right place ...
    (microsoft.public.dotnet.framework.performance)
  • Re: Verifying a User Password - calling crypt()
    ... years ago by calling the encryptfunction on the the user's ... I recall that the encrypt function required a salt ... Can't you use PAM instead? ... I've never used PAM (I've come back to UNIX after a very long time!) ...
    (comp.unix.programmer)
  • Re: Verifying a User Password - calling crypt()
    ... phykell wrote: ... years ago by calling the encryptfunction on the the user's password ... I recall that the encrypt function required a salt value ... Can't you use PAM instead? ...
    (comp.unix.programmer)
Loading