DES encryption

Does anyone have a DES encryption function for xHarbour?

Thanks,
Tim

Dear Tim Jacob:

On Aug 27, 12:34*pm, Tim Jacob <tja...@nospam.jollyfarmer.com> wrote:
....
> Does anyone have a DES encryption function for
> xHarbour?

Do you have one in C? You can easily wrap C code into xHarbour and
"roll your own".

http://www.codeguru.com/forum/showthread.php?t=283093
.... interesting that WinDoze provides an API for this...

David A. Smith

Thanks, David:

I don't, but I'll try to find one.

dlzc wrote:
> Dear Tim Jacob:
>
> On Aug 27, 12:34 pm, Tim Jacob <tja...@nospam.jollyfarmer.com> wrote:
> ...
>> Does anyone have a DES encryption function for
>> xHarbour?
>
> Do you have one in C? You can easily wrap C code into xHarbour and
> "roll your own".
>
> http://www.codeguru.com/forum/showthread.php?t=283093
> ... interesting that WinDoze provides an API for this...
>
> David A. Smith

"Tim Jacob" <tjacob@nospam.jollyfarmer.com> wrote in message
news:48b5ac25$0$4045$9a566e8b@news.aliant.net...
> Does anyone have a DES encryption function for xHarbour?
>
> Thanks,
> Tim

Hi Tim,

I assume you know that the DES (Data Encryption Standard) algorithms were
replaced in late 2001 with the AES (Advanced Encryption Standard). Probably
the best source of information is the NIST (National Institute of Standards
and Technology) web site. As a US Gov web site, it's probably easier to
navigate than most. You can search on the site and the search engine keeps
the search mainly to the NIST site. A good starting place for cryptography
is

http://csrc.nist.gov/groups/ST/toolkit/index.html

One bit of caution, most algorithms you find on the net for crypto are
flawed even for rather simple hash functions like md5 and even the test
vectors are flawed (have incorrect values or aren't sufficiently robust to
detect errors). One case in point is xHarbour's current md5 algorithm is
flawed even though the test vectors used show the algorithm passing.

Hi Bill,
Yes I know that DES is not the method of choice. I just have some data
encrypted (in Clipper) with DES, and I'm trying to do a replacement for
it, while Clipper is still being used on the same data.

Once I no longer need Clipper, I'll probably switch it to AES.

Thanks

bill robertson wrote:
> "Tim Jacob" <tjacob@nospam.jollyfarmer.com> wrote in message
> news:48b5ac25$0$4045$9a566e8b@news.aliant.net...
>> Does anyone have a DES encryption function for xHarbour?
>>
>> Thanks,
>> Tim
>
> Hi Tim,
>
> I assume you know that the DES (Data Encryption Standard) algorithms were
> replaced in late 2001 with the AES (Advanced Encryption Standard). Probably
> the best source of information is the NIST (National Institute of Standards
> and Technology) web site. As a US Gov web site, it's probably easier to
> navigate than most. You can search on the site and the search engine keeps
> the search mainly to the NIST site. A good starting place for cryptography
> is
>
> http://csrc.nist.gov/groups/ST/toolkit/index.html
>
> One bit of caution, most algorithms you find on the net for crypto are
> flawed even for rather simple hash functions like md5 and even the test
> vectors are flawed (have incorrect values or aren't sufficiently robust to
> detect errors). One case in point is xHarbour's current md5 algorithm is
> flawed even though the test vectors used show the algorithm passing.
>
>

"Tim Jacob" <tjacob@nospam.jollyfarmer.com> wrote in message
news:48b68cb9$0$4041$9a566e8b@news.aliant.net...
> Hi Bill,
> Yes I know that DES is not the method of choice. I just have some data
> encrypted (in Clipper) with DES, and I'm trying to do a replacement for
> it, while Clipper is still being used on the same data.
>
> Once I no longer need Clipper, I'll probably switch it to AES.
>
Hi Tim,

Where did the algorithm originate for Clipper? Do you have any source code
or was it from a library? Some library claims weren't all that accurate in
practice. I don't think anyone should use any crypto algorithm unless they
have the source code and they compile it themselves. You don't have to
understand the source code but I have seen and heard many horror stories
when data is lost because this or that library is no longer supported and
the standard algorithm was "improved" for some reason. Now, if the algorithm
is flawed, you still have access to your data.

I wrote some crypto algorithms for Clipper way back when for tea, teax, etc.
I might be able recreate the algorithm for xHarbour even if you don't have
the source code if it conforms to a known standard. Unfortunately, like any
US standard, the DES wasn't an unique standard like CRC-16, CRC-32, MD5,
etc. It has at least four modes of operation and some variations in the
modified Lucifer algorithm which was adopted as the DES.

Do you know which mode was used? The regular mode was ECB (Electronic Code
Book) but there was also a Cipher Block Chaining, a Cipher Feedback and an
Output Feedback mode which changed the way the algorithm used the 64-bit
text block even though the algorithm remained the same.

The good news is that you still have access to your data so you will
immediately know if your xHarbour replacement algorithm works correctly with
your data. The odd thing about crypto is that logic forces you to create and
keep a plaintext copy of all your really important data. I bet you do. Guess
which copy I'm coming after.

It was from a library, DESCRYPT, by Extrasensory Software. It supports
both ECB and CBC. I still do have a working Clipper application, so I
could decrypt everything in Clipper and then encrypt it in xHarbour, but
I was hoping that they'd be able to live side by side for a little while
longer.

bill robertson wrote:
> "Tim Jacob" <tjacob@nospam.jollyfarmer.com> wrote in message
> news:48b68cb9$0$4041$9a566e8b@news.aliant.net...
>> Hi Bill,
>> Yes I know that DES is not the method of choice. I just have some data
>> encrypted (in Clipper) with DES, and I'm trying to do a replacement for
>> it, while Clipper is still being used on the same data.
>>
>> Once I no longer need Clipper, I'll probably switch it to AES.
>>
> Hi Tim,
>
> Where did the algorithm originate for Clipper? Do you have any source code
> or was it from a library? Some library claims weren't all that accurate in
> practice. I don't think anyone should use any crypto algorithm unless they
> have the source code and they compile it themselves. You don't have to
> understand the source code but I have seen and heard many horror stories
> when data is lost because this or that library is no longer supported and
> the standard algorithm was "improved" for some reason. Now, if the algorithm
> is flawed, you still have access to your data.
>
> I wrote some crypto algorithms for Clipper way back when for tea, teax, etc.
> I might be able recreate the algorithm for xHarbour even if you don't have
> the source code if it conforms to a known standard. Unfortunately, like any
> US standard, the DES wasn't an unique standard like CRC-16, CRC-32, MD5,
> etc. It has at least four modes of operation and some variations in the
> modified Lucifer algorithm which was adopted as the DES.
>
> Do you know which mode was used? The regular mode was ECB (Electronic Code
> Book) but there was also a Cipher Block Chaining, a Cipher Feedback and an
> Output Feedback mode which changed the way the algorithm used the 64-bit
> text block even though the algorithm remained the same.
>
> The good news is that you still have access to your data so you will
> immediately know if your xHarbour replacement algorithm works correctly with
> your data. The odd thing about crypto is that logic forces you to create and
> keep a plaintext copy of all your really important data. I bet you do. Guess
> which copy I'm coming after.
>
>

"Tim Jacob" <tjacob@nospam.jollyfarmer.com> wrote in message
news:48b6abe2$0$4026$9a566e8b@news.aliant.net...
> It was from a library, DESCRYPT, by Extrasensory Software. It supports
> both ECB and CBC. I still do have a working Clipper application, so I
> could decrypt everything in Clipper and then encrypt it in xHarbour, but I
> was hoping that they'd be able to live side by side for a little while
> longer.
>
Hi Tim,

Which did you use EBC or CBC? Did you pad the data or let the algorithm pad
using NULLS?

Did you encode the data stream using encode224()? If so, I would need
chr-arrays with chrs from chr(0) to chr(255) encoded with encode224() so
that I could duplicate that algorithm as well. I'm not exactly sure what
would be needed and that could be the most difficult aspect of the process.

If they did something as simple as taking base-256 data and converting that
to (base-224 + 32) data, for example, that's easy. But if they did something
along the lines of MIME content transfer encoding, the so called base-64
encoding techique; that's harder because in the usual interpretation,
base-64 isn't a true mathematical base.

In base-64 encoding, there is a 1-1 mapping of the mathematically exact
values to an arbitrary 64-char dataset. This works because there is an
agreement on the exact character set to be used for each of the base-64
values. Well, almost an agreement, there are some disagreements on the last
2-characters so MIME encoders/decoders have to take this into consideration.

bill robertson wrote:
>>
> Hi Tim,
>
> Which did you use EBC or CBC? Did you pad the data or let the algorithm pad
> using NULLS?
>
> Did you encode the data stream using encode224()? If so, I would need
> chr-arrays with chrs from chr(0) to chr(255) encoded with encode224() so
> that I could duplicate that algorithm as well. I'm not exactly sure what
> would be needed and that could be the most difficult aspect of the process.
>
> If they did something as simple as taking base-256 data and converting that
> to (base-224 + 32) data, for example, that's easy. But if they did something
> along the lines of MIME content transfer encoding, the so called base-64
> encoding techique; that's harder because in the usual interpretation,
> base-64 isn't a true mathematical base.
>
> In base-64 encoding, there is a 1-1 mapping of the mathematically exact
> values to an arbitrary 64-char dataset. This works because there is an
> agreement on the exact character set to be used for each of the base-64
> values. Well, almost an agreement, there are some disagreements on the last
> 2-characters so MIME encoders/decoders have to take this into consideration.
>
>

Hi Bill

I used ECB, and used data that was 16 characters wide (credit card
numbers), padded with spaces if necessary.

I did not use encode224().

Thanks

"Tim Jacob" <tjacob@nospam.jollyfarmer.com> wrote in message
news:48b6c974$0$4023$9a566e8b@news.aliant.net...
> Hi Bill
>
> I used ECB, and used data that was 16 characters wide (credit card
> numbers), padded with spaces if necessary.
>
> I did not use encode224().
>
> Thanks

Hi Tim,

Using ECB (the weaker of the two modes: ECB or CBC) is good for you since
I'm very weak in crypto algorithms. I can barely break caesar's cipher
without my decoder ring.

I have created a small program that I need for you to compile and send to me
via my private address. Then, I can use the algorithm even though I can't
see it or link it into other programs. This should pass the fair-use test
since I'm not asking for any library functions per-say. I included functions
I really don't need in case they prove easily cloned and this problem shows
again up in slightly different form.

/* ESP Cipher Test

If Pgm Name is : ESP.prg
Compile with : clipper ESP /m/n/b
and Link with: rtlink fi ESP lib cld

I prefer rtlink in case I decide to look
the byte codes, but any linker is OK.
*/

#include "INKEY.ch"

FUNCTION Main()
LOCAL PlainText, CipherText, InitVector, cKey
LOCAL cBuffer, GETLIST:= {}

ALTD()

PlainText:= CipherText:= InitVector:= cKey:= SPACE(8)

CLEAR SCREEN
@ 1, 3 say "ExtraSensory DesCrypt Algorithm"

WHILE ( DevPos(4,3), ;
DEVOUT("{Esc] to Exit, any other Key for the next round"), ;
( INKEY( 0 ) != K_ESC ) ;
)

@ 4, 3 say SPACE(50)
@ 5, 3 say "Text to Encrypt: " GET PlainText
@ 6, 3 say "Key Key : " GET cKey
@ 7, 3 say "InitVector(ECB): " GET InitVector
READ

CipherText := EncryptBlk(PlainText , cKey)
PlainText := DecryptBlk(Ciphertext, cKey)
@ 9, 3 say "CBC CipherText: " + CipherText
@10, 3 say "CBC PlainText : " + PlainText

CipherText := EncryptStr(PlainText , cKey)
PlainText := DecryptStr(Ciphertext, cKey)
@12, 3 say "ECB CipherText: " + CipherText
@13, 3 say "ECB PlainText : " + PlainText

CipherText := Password( cKey )
cBuffer := EnCode224( PlainText )
cBuffer := DeCode224( PlainText )

END WHILE

RETURN 0