Re: [Firebird-devel] RFC: Adding a cryptographic library for use in firebird

[Adriano d. S. F. <adr...@uo...>]

Mark O'Donohue wrote:
> Hi All
>
> I would like to add a general cryptographic library of functions for
> usage in Firebird.
>   
First, AFAIK strong encription is not allowed on some countries. How do 
we deal with it?

What is the library source and binary size? Would they will be required 
or FB can work without them? How it work without them?

> There are many Firebird enhancements that have been suggested:
> encrypted disk images; secure client connection handshake;  encrypted
> backups (aka Borland Interbase); even digitally encrypted and signed
> BLR routines; and native SSL engine support.    A key enabler of those
> features is the availability of a general set of cryptographic
> functions in the engine.  I would like to add an FBCrypto interface
> class that provides those functions.
>   
I don't think it should be done for v2.5, as all these benefits will not 
be achieved, and there are important points (questions above, plugin 
discussions) to resolve.

> The FBCrypto class adds a C++ friendly layer over the top of the
> OpenSSL libraries, and provides access to the cryptographic routines
> without exposing the openssl implementation details.
Is OpenSSL modular enough for we use just the crypto routines, and not 
the whole library including SSL sockets?

>    As a first step
> in introducing the library, I also propose adding a number of SQL
> system functions, that make use of this library to perform
> encryption/hashing and general base64 encoding and decoding.
>   
For hashing functions, I think the HASH system function should be 
extended with a new parameters. But to describe the return type 
correctly, the algorithm should be evaluated at compilation phase.

>
> The interface classes are described here:
>
>        http://www.eftel.com.au/~mark.odonohue/FBCrypto.html
>        http://www.eftel.com.au/~mark.odonohue/ByteArray.html
>   
Why ByteArray? We already have array classes. Also, won't the crypto 
functions works in chunks of bytes?

> Here is a sample usage,  taken from the prototype encrypt system
> function implementation:
>
> 	Encryptor enc = FBCrypto::getEncryptor();
> 	enc.setCipher(cipherName);
> 	enc.setPassphrase(passphrase);
> 	enc.initEncrypt();
> 	ByteArray encResult = enc.encrypt(rawData);
>
>
> And the suggested additional SQL system functions are:
>
>            encrypt(cipherName, keyphrase, data)
>            decrypt(cipherName, keyphrase, data)
>
>            createdigest(digestName, data)
>            verifydigest(digestName, digest, data)
>
>            base64encode(data)
>            base64decode(b64string)
>
>            hexencode(data)
>            hexdecode(hexstring)
>
>
> With example usage:
>
>            update table1 set encblob = encrypt('AES128','secret', datablob))
>
>            update table1 set signature = createdigest('SHA256', datablob))
>
>            select base64encode(encblob) from table1;
>
> Currently only the first two  functions are implemented, although all
> the underlying C++ functions exist.  The encrypt function takes string
> or blob data, and returns binary string or binary blob, depending on
> the input data type.
Does it works in chunks for blobs?

>    The return result for decrypt, is a binary
> string or binary blob, and will need to be cast to the appropriate
> type, although this could use octet strings.
>   
I do not like the need to cast. This is another point that could be 
resolved in v3.


Adriano