Crypt's

[Qatan]

Hello all,

 

    I need to crypt / decrypt some strings (for password) and I found some functions to do it:

 

    CRYPT()

    HB_CRYPT()  / HB_DECRYPT()

    SX_ENCRYPT / SX_DECRYPT()

   

    So seems that any could work, but what is the difference? Anyone uses any?

    I would like to know a bit more based on the other user’s experiences.

    Thanks

 

Qatan

 

[Klas Engwall]

Hi Qatan,

> I need to crypt / decrypt some strings (for password) and I found
> some functions to do it:
> CRYPT()
> HB_CRYPT() / HB_DECRYPT()
> SX_ENCRYPT / SX_DECRYPT()
> So seems that any could work, but what is the difference? Anyone
> uses any?

> I would like to know a bit more based on the other user�s experiences.
> Thanks

You forgot the fourth solution :-)

hb_blowfishEncrypt() / hb_blowfishDecrypt()

I use Blowfish for everything (although for historical reasons the
version from HwGui). I encrypt passwords in a Clipper app and decrypt
them in my Harbour EDI converter to log into remote FTP servers. I have
had no problems whatsoever. And it is considered a very safe cipher.

http://en.wikipedia.org/wiki/Blowfish_%28cipher%29

I know that Crypt() is Clipper Tools compatible. That should make it
slightly safer than the simple xor-based Funcky encryption I used in a
previous life. I have never investigated the other options you mentioned.

Regards,
Klas

[Bernard Mouille]

Hello Quantan,

You can find a basic sample to test hb_blowfishEncrypt() and decrypt :

http://bernard.mouille.free.fr/0_Harbour/ZD00000018/000002.html

Good developpement,

Bernard

[vszakats]

I know that Crypt() is Clipper Tools compatible. That should make it

It's a very simple "cipher". I actually reverse engineered 

it from ASM code ~15 years ago. Not recommended for 

anything serious.

-- Viktor

[Qatan]

Hello Bernard,

Very nice example. It is what I was looking for.
Your site has interesting examples.
Merci pour l'aide.

Qatan

> I would like to know a bit more based on the other user�s experiences.
> Thanks
>
> Qatan

--
You received this message because you are subscribed to the Google
Groups "Harbour Users" group.
Unsubscribe: harbour-user...@googlegroups.com
Web: http://groups.google.com/group/harbour-users

[Qatan]

Hello Klas,

I will use blowfish, seems very good and with Bernard's example it is
even easier.
Thanks for sharing your experience.
Regards,

Qatan

[Qatan]

Hello Viktor,

 

    Thanks for answering and sharing a bit about Crypt() history.

    It is interesting to know and understand where it came from and what it does.

    I will follows Klas advise to use hb_blowfish*() that seems interesting and safe (although I just need to make a simple login/password routine for a simple program...)

 

    By the way, do you know it sx_DbfEncrypt() / sx_DbfDecrypt() uses blowfish? I belive it doesn’t (maybe because it should be compatible with Six?)

    Anyway I found what Przemek wrote: “I still do not allow to encrypt tables with memo fields to not replicate Six3 bugs which may cause data corruption.” (Changelog 2007-09-25 03:20 UTC+0200 Przemyslaw Czerpak) so no encryption for memo fields than I thought: “Why not use blowfish?” The answer is probably because of compatibility with Six3 right?

    But what if I do not need compatibility? I just want to understand. (maybe someone uses Six in a Clipper program and a Harbour program on the same database? Is this the motive?)

 

   Regards,

 

Qatan

 

 

From: vszakats

Sent: Wednesday, September 12, 2012 7:07 AM

To: harbou...@googlegroups.com

Subject: Re: [harbour-users] Crypt's

 

I know that Crypt() is Clipper Tools compatible. That should make it

[Bernard Mouille]

Hello Qatan,

Thank's for your compliment, my web site is little but it'is bigger
every month : I use Harbour only from Juy 2011.

You can compare in Harbour 3.0.0 or night version :

sx_DbfEncrypt() / sx_DbfDecrypt() -> \src\rdd\hbsix\sxtable.c

hb_blowfishEncrypt() / hb_blowfishDecrypt() -> \src\rtl\hbbffnc.c

Bernard

[vszakats]

Hi Qatan,

On Wednesday, September 12, 2012 9:35:06 AM UTC+2, Qatan wrote:

    By the way, do you know it sx_DbfEncrypt() / sx_DbfDecrypt() uses blowfish? I belive it doesn’t (maybe because it should be compatible with Six?)

    Anyway I found what Przemek wrote: “I still do not allow to encrypt tables with memo fields to not replicate Six3 bugs which may cause data corruption.” (Changelog 2007-09-25 03:20 UTC+0200 Przemyslaw Czerpak) so no encryption for memo fields than I thought: “Why not use blowfish?” The answer is probably because of compatibility with Six3 right?

Exactly.

    But what if I do not need compatibility? I just want to understand. (maybe someone uses Six in a Clipper program and a Harbour program on the same database? Is this the motive?)

Six emulation library is a compatibility API, 

so it should stay true to the original. If you 

don't need Six compatibility, you just use 

something else. BTW, these are standalone 

functions, so there is no point in sticking to 

the Six library here.

If the question is encrypting complete tables 

on RDD level, it's a different matter, but IMO 

the whole point is moot due to the many 

shortages of current system. F.e. index keys 

will reveal sensitive data. Security is always 

defined by the weakest link, and this link in 

case of storing passwords is the storage of

the encryption key. It's better to store passwords 

in the form of salted hashes (f.e. HMAC-SHA).

-- Viktor

[Maurizio la Cecilia]

Hi Bernard,
I'm asking if the blowfish encryption could result in a hb_Eof() char/pair to be inserted in the crypted string.
If so, the file in your sample could be wrongly decrypted.
Maurizio

[Bernard Mouille]

Hello Maurizio,

Thank's for your comment.
I do not know if blowfish encryption could result in a hb_Eof() char/
pair.
My sample is a basic sample with txt'files to view how it's work to
understand blowfish.
I hope that blowfish'crypt do not use chr(10) nor chr(13).
I use blowfish only to crypt the datas in dbf'fields.

Bernard

On 12 sep, 10:21, Maurizio la Cecilia <m.laceci...@gmail.com> wrote:
> Hi Bernard,
> I'm asking if the blowfish encryption could result in a hb_Eof() char/pair
> to be inserted in the crypted string.
> If so, the file in your sample could be wrongly decrypted.
> Maurizio

> Il giorno 12/set/2012 05:45, "Bernard Mouille" <bernard.moui...@wanadoo.fr>
> ha scritto:

[Qatan]

Hello Bernard / Maurizio,

What about memoread() / memowrit()? Would work better?

Qatan

-----Original Message-----
From: Bernard Mouille
Sent: Wednesday, September 12, 2012 10:45 AM
To: Harbour Users
Subject: [harbour-users] Re: Crypt's

[Bernard Mouille]

Hello Qatan,

Sorry, I do not use memoread() / memowrit().

Bernard

[Alejandro Padrino]

Since 2003 year I'm working in my own cryptographic algorithm.  At this moment there is two releases, and now I'm making the third release.  Entropy for PSA Encryption is about 7.84 and its security was not broken.  For the last PSA-02 release I'm including new security elements.  Not needed, but want to do the best encryption I can think.  This release includes Harbour-Clipper-FreeBasic compatibility, and think will work fine with some Delphi compilers (not for Delphi-4 because its errors in math calculations).  My error in all past years is trying to get money with my projects, nobody appears to be interested.  I'm without work, without future, and can't think in giving for free my projects (I have more projects for IT Security).  I'm Spaniard.

[Qatan]

Hello Bernard,

Thanks for the tips. I will need both.
Regards,

Qatan


-----Original Message-----
From: Bernard Mouille
Sent: Wednesday, September 12, 2012 9:59 AM
To: Harbour Users
Subject: [harbour-users] Re: Crypt's

[Qatan]

Hello Viktor,

 

But what if I do not need compatibility? I just want to understand. (maybe someone uses Six in a Clipper program and a Harbour program on the same database? Is this the motive?)

>Six emulation library is a compatibility API,

>so it should stay true to the original. If you

>don't need Six compatibility, you just use

>something else. BTW, these are standalone

>functions, so there is no point in sticking to

>the Six library here.

>If the question is encrypting complete tables

>on RDD level, it's a different matter, but IMO

>the whole point is moot due to the many

>shortages of current system. F.e. index keys

>will reveal sensitive data. Security is always

>defined by the weakest link, and this link in

>case of storing passwords is the storage of

>the encryption key. It's better to store passwords

>in the form of salted hashes (f.e. HMAC-SHA).

 

I see...

 

The idea was for the RDD level.

So the only solution would be to rethink and maybe create “HBRDD” with all the nice features of DBFNSX + fixes + hb_locking_schema + blowfish_security? In other words, do right what should be done with Six in the past.

Well, not for me! At least now I understand more – thanks for explaining.

I think I will use DBFNSX with sx_dbf*() functions. It will be enough for my case because security will not be a issue, just to avoid leaving the way too easy for curious people and I can also use hb_blowfish*() wherever possible.

Regads,

 

Qatan

 

 

[Qatan]

Hello Bernard,

I tried to see differences.
Here you are my testing code:

------>8------

/*
* Test of Crypto functions
*
* hbmk2 test -lxhb
*
*/

PROCEDURE Main()

LOCAL cText := 'Test of crypto...'

LOCAL cKey := 'cryptoX123test'

LOCAL cBlow1 := hb_blowfishEncrypt( hb_blowfishKey( cKey ), cText )
LOCAL cBlow2 := hb_blowfishDecrypt( hb_blowfishKey( cKey ), cBlow1 )

LOCAL cSix1 := sx_encrypt( cText, cKey )
LOCAL cSix2 := sx_decrypt( cSix1, cKey )

LOCAL cXhb1 := hb_crypt( cText, cKey )
LOCAL cXhb2 := hb_decrypt( cXhb1, cKey )

SETMODE( 25,80 )
CLS

? cText, LEN( cText )
?
? cKey, LEN( cKey )
?
? cBlow1, LEN( cBlow1 )
? cBlow2, LEN( cBlow2 )
?
? cSix1, LEN( cSix1 )
? cSix2, LEN( cSix2 )
?
? cXhb1, LEN( cXhb1 )
? cXhb2, LEN( cXhb2 )
?

RETURN
------8<------

Qatan


-----Original Message-----
From: Bernard Mouille
Sent: Wednesday, September 12, 2012 9:59 AM
To: Harbour Users
Subject: [harbour-users] Re: Crypt's

[Bernard Mouille]

Thank's Qatan.
Bernard

On 12 sep, 12:54, "Qatan" <wanstad...@gmail.com> wrote:
> Hello Bernard,
>

[Bernard Mouille]

Hello Alejandro,

I am sorry that you have no work.
In Harbour, I think :
- Nobody is obliged to give source or example,
- Developpers make à very good free work for everybody,
- Users ask and answer the questions if they want.

A big thank you to Developpers and Users forums, I learn Harbour with
this forums.
A big thank you to mens and womens that have a web site with Harbour
notices.

Good luck for the future,

Bernard

[Alejandro Padrino]

Thanks Bernard,

life is to fight every day, simply as this. I'm thinking in ways to licensing new release. Source code always be private because releasing it to the public allows everybody to stole my work. But think than demo software can be licensed by Creative Commons. Professional release will be very cheap for developers and Anonymous members. I need many time to finish because there is some things to try and research.

Best,

Alejandro.

[Klas Engwall]

Hi Viktor,

> I know that Crypt() is Clipper Tools compatible. That should make it
>
>
> It's a very simple "cipher".

Which is why I called it "slightly" better than the one at the bottom :-)

Regards,
Klas

[Klas Engwall]

Hi Qatan,

> I will use blowfish, seems very good and with Bernard's example it is
> even easier.

Yesterday you said you needed to both encrypt and decrypt the passwords.
Today you said you only need those passwords for logging inte your
application. If that is what you mean, then you do not need to decrypt
anything, and Viktor's suggestion to use a hash is better. A hash is a
"one way street". A hash cannot be "unhashed". So you make a hash of the
original password (plus preferably a salt) and save the hash. Then you
make a hash of the user's password (with the same salt) when attempting
to log in, and you compare the two hashes with each other. The
difference with what I do is that I need to retrieve the saved password
and use it on a remote system later on. In my applications it it just "a
piece of data".

Regards,
Klas

[Klas Engwall]

Hi Qatan,

> What about memoread() / memowrit()? Would work better?

Convert the encrypted string to hex and then save it any way you like.
It will keep you out of trouble with various special characters and will
also save you from the risk that automatic codepage conversion alters
the encrypted string if you use different _SET_CODEPAGE and _SET_DBCODEPAGE.

Regards,
Klas

[Qatan]

Hello Klas,

Sorry for the confusion. Really I need both...
I thought about encrypting not only login passwords but also sensitive
data and even databases... I am thinking about all the possibilities of
encryption / decryption and I am trying to learn what are the options and
for what so I can somehow apply those that will fit in the different
situations.
What I mean is that I don't really know yet what to use, how and
where... but I am starting to have an idea based on all the nice
explanations and suggestions of you all. Forums are rich!
By the way I like your (also Viktor's) suggestion about salted hashes
(HMCA-SHA) but... I have no idea what is it! If you could provide an example
of use it would be great. What I found is: \contrib\hbssl\tests but the
tests (examples) were a bit too complicated for me (I got the impression I
would encrypt something and would never be able to decrypt it...) probably
because I am not familiar to those methods, SSL, SHA1/2, HMCA, salted
hashes, etc...)
Thanks for all the support.

Regards,

Qatan


-----Original Message-----
From: Klas Engwall
Sent: Thursday, September 13, 2012 12:54 AM
To: harbou...@googlegroups.com
Subject: Re: [harbour-users] Crypt's

[Qatan]

Hello Klas,

Good idea. I will do it to test but I was reading MEMOWRIT() info on the
manual and it says:

Note: the function writes an end-of-file marker (Chr(26)) to the created
file. That means, the file created by MemoWrit() contains one byte more than
the input string <cString>. This must be taken into consideration if the
file is later read using MemoRead().

How to avoid that extra byte? Or how to delete that extra byte so the
file will keep original? I do not want it to have that Chr(26) on the end.

Thanks for any help.

Qatan


-----Original Message-----
From: Klas Engwall
Sent: Thursday, September 13, 2012 1:06 AM
To: harbou...@googlegroups.com

[Qatan]

Hello Klas / Bernard,

Follows the test the way Klas suggested:
(The only problem is that I didn't find a "simple" way of removing the
last byte automatically added by MEMOWRIT())

------8<------
PROCEDURE Main()

// Key for the blowfish routine
LOCAL cKey := hb_blowfishkey( 'test' )
LOCAL cFile
LOCAL cTemp

// Simple adjustment for the screen size
SETMODE(25,80)
CLS

// Cleanning possible old files
IF FILE( "00_*.txt" ); FERASE( "00_*.txt" ); ENDIF

// Selecting a file to test
?;? "Selecting a file to encrypt / decrypt (the orginal file will not be
touched)"
cFile := WIN_GETOPENFILENAME()
IF EMPTY( cFile )
?;? "You must to select a file"
QUIT
ENDIF

// Making a copy of the original file so we do not change anything by
accident
hb_fCopy( cFile, "00_Original.txt" )


// Crypting the file
cTemp := MEMOREAD( "00_Original.txt" )
cTemp := hb_blowfishEncrypt( cKey, cTemp )
cTemp := hb_StrToHex( cTemp )
MEMOWRIT( "_Encrypted.txt", cTemp )

// Decrypting the file
cTemp := MEMOREAD( "00_Encrypted.txt" )
cTemp := hb_HexToStr( cTemp )
cTemp := hb_blowfishDecrypt( cKey, cTemp )
MEMOWRIT( "00_Decrypted.txt", cTemp )

?;? "Done!"

RETURN
------>8------

-----Original Message-----
From: Klas Engwall
Sent: Thursday, September 13, 2012 1:06 AM
To: harbou...@googlegroups.com
Subject: Re: [harbour-users] Re: Crypt's

[francesco perillo]

use fopen/fwrite/fread/fclose instead of memoread/write

Unsubscribe: harbour-users+unsubscribe@googlegroups.com
Web: http://groups.google.com/group/harbour-users

--
You received this message because you are subscribed to the Google
Groups "Harbour Users" group.

Unsubscribe: harbour-users+unsubscribe@googlegroups.com
Web: http://groups.google.com/group/harbour-users

[Qatan]

Hello Francesco,

 

    OK, seems the best solution.

    Thanks

 

Qatan

Unsubscribe: harbour-user...@googlegroups.com
Web: http://groups.google.com/group/harbour-users

[vszakats]

Note:  the function writes an end-of-file marker (Chr(26)) to the created
file. That means, the file created by MemoWrit() contains one byte more than
the input string <cString>. This must be taken into consideration if the
file is later read using MemoRead().

    How to avoid that extra byte? Or how to delete that extra byte so the
file will keep original? I do not want it to have that Chr(26) on the end.

Use HB_MEMOWRIT()/HB_MEMOREAD(). However, if you use 

MEMOREAD() to read file written with MEMOWRIT(), it will automatically 

strip the EOF byte from the end.

-- Viktor

[Przemyslaw Czerpak]

On Wed, 12 Sep 2012, Qatan wrote:

Hi,

> By the way, do you know it sx_DbfEncrypt() / sx_DbfDecrypt() uses blowfish?
> I belive it doesn’t (maybe because it should be compatible with Six?)

It uses the same encryption as sx_enCrypt() / sx_deCrypt().
This encryption uses 64bit seed to encode serialized bytes.
For sure it's much stronger then xor or other simple encryption
but in current days of very fast computers for sure cannot be
called save encryption and for sure it's not safe for good mathematician
even without computer (in 1932 Polish mathematicians broke Enigma
encryption without any electronic computers but Rejewski, Różycki
and Zygalski were geniuses who created whole new mathethical theory
which is still used).

> Anyway I found what Przemek wrote: “I still do not allow to encrypt tables
> with memo fields to not replicate Six3 bugs which may cause data corruption.”

This is problem with SIX3 implementation not encryption efficiency.
If you look at SIX3 encryption then you will find that you can encrypt/decrypt
single records. The problem is that in some cases only data in DBF is encrypted
but not in memo but the flag is set for whole record so on reading unencrypted
data from memo is deciphered giving wrong results. For some fields like
"V", 20, 0
Part of string is stored in DBF and the rest for longer strings in memo
file. Such fields after decoding are partially broken, etc.
To implement it well it's necessary do drop SIX3 compatibility and it was
the reason I leave it as is blocking encryption for tables with memos.

> (Changelog 2007-09-25 03:20 UTC+0200 Przemyslaw Czerpak) so no encryption for
> memo fields than I thought: “Why not use blowfish?” The answer is probably
> because of compatibility with Six3 right?
> But what if I do not need compatibility? I just want to understand. (maybe
> someone uses Six in a Clipper program and a Harbour program on the same
> database? Is this the motive?)

Exactly. Harbour can share encrypted tables with SIX3 Clipper applications
if they do not use memo fields.
We can add BlowFish encryption to Harbour DBF* RDDs but it should be wider
implementation then SIX3 one which does not touch few things like indexes
from which keys can be read by anyone.
There is only question if it's worth to touch RDD to reach such effect.
Few years ago I added to Harbour new file IO meta layer and updated all
native RDDs to use it. So far we have two drivers using this meta layer:
NETIO written by me and MEMIO written by Mindaugas. Looks that other
developers still do not see how powerful is this extension.
It's possible to write new driver, i.e. BFIO (BlowFishIO) which will crypt
and decrypt all data written to and read from files. It can be implemented
in few hours by anyone with some knowledge about C and Harbour internals.
It can even use replaceable encryption methods. Using CFB (cipher feedback)
encryption mode then we can also use any hash function as base for
encryption algorithm.
Below I'm attaching simple example which uses MD5 hash function to encode
and decode text. Please remember that CFB encryption method does not change
the size of encrypted data what can be important in some cases, i.e. fixed
field size in tables or variable length datagram encoding.

best regards,
Przemek

/*************************************************************************/
proc main()
test( "This is a top secret message only by trusted people." )
?
test( repl( "A", 63 ) )
return

proc test( text )
local cipher, result
cipher := HB_MD5ENCRYPT( text , "top-secret" )
result := HB_MD5DECRYPT( cipher, "top-secret" )
? len( text ), hb_valToExp( text )
? len( cipher ), hb_valToExp( cipher )
? len( result ), hb_valToExp( result )
? text == result, iif( text == result, "OK", "ERROR" )
return

/*************************************************************************/

#pragma begindump
#include "hbapi.h"
#include "hbapiitm.h"
#include "hbchksum.h"

/*
* Harbour Project source code:
* PRG functions for MD5 encryption/decryption using
* CFB (cipher feedback) mode
*
* Copyright 2011 Przemyslaw Czerpak <druzus / at / priv.onet.pl>
* www - http://harbour-project.org
*/


static void hb_md5_init_seed( char * vect, const char * pszKey, int iLen )
{
hb_md5( pszKey, iLen, vect );
}

static void hb_md5_next_seed( char * vect, const char * pszKey, int iLen )
{
int i;
for( i = 0; i < 16; ++i )
vect[ i ] ^= pszKey[ i % iLen ];
hb_md5( vect, 16, vect );
}

/* HB_MD5ENCRYPT( <cText>, <cPasswd> ) -> <cCipher>
*/
HB_FUNC( HB_MD5ENCRYPT )
{
PHB_ITEM pData = hb_param( 1, HB_IT_STRING );

if( pData && hb_parclen( 2 ) > 0 )
{
HB_SIZE nLen = hb_itemGetCLen( pData ), n;

if( nLen )
{
const char * pszSource = hb_itemGetCPtr( pData );
char * pszData = ( char * ) hb_xgrab( nLen + 1 );
const char * pszKey = hb_parc( 2 );
int iLen = ( int ) hb_parclen( 2 );
char vect[ 16 ];

hb_md5_init_seed( vect, pszKey, iLen );

for( n = 0; n < nLen; ++n )
{
int i = ( int ) ( n & 0x0F );
if( i == 0 )
hb_md5_next_seed( vect, pszKey, iLen );
pszData[ n ] = ( vect[ i ] ^= pszSource[ n ] );
}
hb_retclen_buffer( pszData, nLen );
}
else
hb_retc_null();
}
}

/* HB_MD5DECRYPT( <cCipher>, <cPasswd> ] ) -> <cText>
*/
HB_FUNC( HB_MD5DECRYPT )
{
PHB_ITEM pData = hb_param( 1, HB_IT_STRING );

if( pData && hb_parclen( 2 ) > 0 )
{
HB_SIZE nLen = hb_itemGetCLen( pData ), n;

if( nLen )
{
const char * pszSource = hb_itemGetCPtr( pData );
char * pszData = ( char * ) hb_xgrab( nLen + 1 );
const char * pszKey = hb_parc( 2 );
int iLen = ( int ) hb_parclen( 2 );
char vect[ 16 ];

hb_md5_init_seed( vect, pszKey, iLen );

for( n = 0; n < nLen; ++n )
{
int i = ( int ) ( n & 0x0F );
if( i == 0 )
hb_md5_next_seed( vect, pszKey, iLen );
pszData[ n ] = ( vect[ i ] ^ pszSource[ n ] );
vect[ i ] = pszSource[ n ];
}
hb_retclen_buffer( pszData, nLen );
}
else
hb_retc_null();
}
}
#pragma enddump
/*************************************************************************/

[vszakats]

Hi Przemek,

This could go right into hbrtl :)

-- Viktor

[Bernard Mouille]

Hello,

Like said Maurizio yesterday, chr(10) and chr(13) are used in
hb_blowfishEncrypt() .

I can decript a file with FREADLINE(), but not with FREAD()

Bernard

[Qatan]

Hello Viktor,

 

    That’s it!

    I was in the way of doing it with FOPEN / FREAD / FSEEK / FWRITE / FCLOSE but it was going to be a bit difficult to me. Maybe Francesco could show how to do the same with those functions (I really do not know how). It would be interesting to see how it works.

 

    Follows the test based on Bernard’s first test with Klas suggestions and help from Viktor (Thanks to all!)

 

Qatan

 

 

------8<------

#include "directry.ch"

  

PROCEDURE Main()

 

  LOCAL cKey  := hb_blowfishkey( "test" )

  LOCAL cFile

  LOCAL cTemp

  LOCAL aFiles

 

  SETMODE( 25,80 )

  CLS

 

   // Cleanning possible old files

   aFiles := DIRECTORY( "00_*.txt" )

      AEVAL( aFiles, { |aFile| FERASE( aFile[ F_NAME ] ) } )

 

   // Selecting a file to test

   cFile := WIN_GETOPENFILENAME()

   IF EMPTY( cFile )

      ALERT( "You must to select a file" )

      QUIT

   ENDIF

 

   // Making a copy of the original file so we do not change anything by accident

   hb_fCopy( cFile, "00_Original.txt" )

 

   // Crypting the file

   cTemp := HB_MEMOREAD( "00_Original.txt" )

   cTemp := hb_blowfishEncrypt( cKey, cTemp )

   cTemp := hb_StrToHex( cTemp )

   HB_MEMOWRIT( "00_Encrypted.txt", cTemp )

 

   // Decrypting the file

   cTemp := HB_MEMOREAD( "00_Encrypted.txt" )

   cTemp := hb_HexToStr( cTemp )

   cTemp := hb_blowfishDecrypt( cKey, cTemp )

   HB_MEMOWRIT( "00_Decrypted.txt", cTemp )

 

   ALERT( "Done!" )

 

RETURN

------>8------

 

From: vszakats

Sent: Thursday, September 13, 2012 11:15 AM

To: harbou...@googlegroups.com

Subject: Re: [harbour-users] Re: Crypt's

 

Note:  the function writes an end-of-file marker (Chr(26)) to the created

[Qatan]

Hello Przemek,

I know the history about the Polish mathematicians and enigma machine -
It is really impressive.
Your idea and code seems very interesting!
I feel I can not ask anyone to for such a task (I would like to do
myself but I am not the right person...) But for sure I would like to use
this *new* RDD if it would became reality.
Thanks for explaining about Six3.
I agree with Viktor about going right into hbrtl (+1)

Qatan

[Qatan]

Hello Przemek,

I did a simple test decrypting a .EXE file and decrypting it for later
use (with that example program I in my last email)
The bad side effect is that it increased the size of the file more or
less 2x
The MD5 method does not change unless I use hb_StrToHex() /
hb_HexToStr() so it seems interesting.
But without using hb_StrToHex() we would not have that problem Klas
mentioned?

"
Convert the encrypted string to hex and then save it any way you like.
It will keep you out of trouble with various special characters and will
also save you from the risk that automatic codepage conversion alters
the encrypted string if you use different _SET_CODEPAGE and _SET_DBCODEPAGE.

" ~ Klas Engwall

Follows example code (based or every ones on this thread incl. your):

Qatan

------8<------
#include "directry.ch"

PROCEDURE Main()

LOCAL cKey := "top-secret"

LOCAL cFile
LOCAL cTemp
LOCAL aFiles

SETMODE( 25,80 )
CLS

// Cleanning possible old files
aFiles := DIRECTORY( "00_*.txt" )
AEVAL( aFiles, { |aFile| FERASE( aFile[ F_NAME ] ) } )

// Selecting a file to test
cFile := WIN_GETOPENFILENAME()
IF EMPTY( cFile )
ALERT( "You must to select a file" )
QUIT
ENDIF

// Making a copy of the original file so we do not change anything by
accident
hb_fCopy( cFile, "00_Original.txt" )

// Crypting the file
cTemp := HB_MEMOREAD( "00_Original.txt" )

cTemp := HB_MD5ENCRYPT( cTemp, "top-secret" )

HB_MEMOWRIT( "00_Encrypted.txt", cTemp )

// Decrypting the file
cTemp := HB_MEMOREAD( "00_Encrypted.txt" )

cTemp := HB_MD5DECRYPT( cTemp, "top-secret" )

HB_MEMOWRIT( "00_Decrypted.txt", cTemp )

ALERT( "Done!" )

RETURN

------>8------

[Przemyslaw Czerpak]

On Thu, 13 Sep 2012, vszakats wrote:

Hi Viktor,

> This could go right into hbrtl :)

I'll commit it and also add:

hb_blowfishEncrypt_CFB( <cBfKey>, <cText> [, <cInitSeed> ] ) -> <cCipher>
hb_blowfishDecrypt_CFB( <cBfKey>, <cCipher> [, <cInitSeed> ] ) -> <cText>

best regards,
Przemek

[Klas Engwall]

Hi Qatan,

> Sorry for the confusion. Really I need both...
> I thought about encrypting not only login passwords but also sensitive
> data and even databases... I am thinking about all the possibilities of
> encryption / decryption and I am trying to learn what are the options and
> for what so I can somehow apply those that will fit in the different
> situations.

OK :-)

> What I mean is that I don't really know yet what to use, how and
> where... but I am starting to have an idea based on all the nice
> explanations and suggestions of you all. Forums are rich!
> By the way I like your (also Viktor's) suggestion about salted hashes
>
> (HMCA-SHA) but... I have no idea what is it! If you could provide an example
> of use it would be great. What I found is: \contrib\hbssl\tests but the
> tests (examples) were a bit too complicated for me (I got the impression I
> would encrypt something and would never be able to decrypt it...) probably
> because I am not familiar to those methods, SSL, SHA1/2, HMCA, salted
> hashes, etc...)

A lot has been written on the web about all the different approaches to
encryption, both in layman's terms and in fancy language. So I think
that the best thing you can do is to look up some of that. I have no
specific links to suggest except that Wikipedia is probably a good place
to start.

Google is your friend (well, at least in this case) :-).

Regards,
Klas

[wanst...@gmail.com]

Hi to all,

I got a message from Félix:

I've seen https://groups.google.com/u/1/g/harbour-users/c/mWHZJPAixK4?pli=1

But Bernard's  samples on http://bernard.mouille.free.fr/0_Harbour/ZD00000018/000002.html is not available.

Please, could you send us samples ?

TIA!

Kind regards,

Félix Pablo Grande Ramos

“Mi conciencia tiene para mí más peso que la opinión de todo el mundo.”
Marco Tulio Cicerón.

So here is sample of use of it:

---8<---

#include "directry.ch"

   

PROCEDURE Main()

  LOCAL cKey  := "top-secret"

  LOCAL cFile

  LOCAL cTemp

  LOCAL aFiles

  SETMODE( 25,80 )

  CLS

   // Cleanning possible old files

   aFiles := DIRECTORY( "00_*.txt" )

   AEVAL( aFiles, { |aFile| FERASE( aFile[ F_NAME ] ) } )

   // Selecting a file to test

   cFile := WIN_GETOPENFILENAME()

   IF EMPTY( cFile )

      ALERT( "You must to select a file" )

      QUIT

   ENDIF

   // Making a copy of the original file so we do not change anything by accident

   hb_fCopy( cFile, "00_Original.txt" )

   // Crypting the file

   cTemp := HB_MEMOREAD( "00_Original.txt" )

   cTemp := HB_MD5ENCRYPT( cTemp, "top-secret" )

   cTemp := hb_StrToHex( cTemp )

   HB_MEMOWRIT( "00_Encrypted.txt", cTemp )

   // Decrypting the file

   cTemp := HB_MEMOREAD( "00_Encrypted.txt" )

   cTemp := hb_HexToStr( cTemp )

--->8----

And here other sample code:

--->8---

---8<--- 

Attached both codes to build and test.

You need to create a simple text file "00_Original.txt") - I've tested with huge files and it works very well

Have fun!

Best Regards to ALL!

[Baxajaun]

Thanks to Bernard and Mario !!!

Kind regards,

[Yakano]

Hi 

Is there a difference between FileStr(cFile) and hb_MemoRead(cFile) ???

Best regards

[Bernard Mouille]

Hello Yakano,

Clipper Reference Guide · Clipper Tools 3 (harbour.github.io)

Harbour Reference Guide · Harbour core

Regards,

Bernard.

[Yakano]

Hi Bernard

Yes, I had read both specifications, but I can't find any differences when FileStr(cFile) doesn't include more parameters, that is, [<nLength>], [<nOffset>],  [<lCtrl-Z>] not included.

Best regards

[Klas Engwall]

Hi Yakano,

> Yes, I had read both specifications, but I can't find any differences
> when FileStr(cFile) doesn't include more parameters, that is,
> [<nLength>], [<nOffset>],  [<lCtrl-Z>] not included.

You are looking at them through glasses from 2022, but you actually need
glasses from the 1980s. Don't forget that Clipper Tools was en extra
commercial offering on top of Clipper itself. Most Clipper users did use
MemoRead() but some purchased CT and used the improved file reader
FileStr(). Both versions were implemented in Harbour - and also an
improved hb_MemoRead() - so both user categories could move from Clipper
to Harbour with no need to change their function calls. There are many
similar examples in Harbour.

Regards,
Klas

[Yakano]

Hi Klass

Yes you're right. 

Although I don't do the password encryption tasks yet, I plan to do it in the near future and I was wondering if there would be any difference between using one or the other function.

Best Regards