While there are many different ways to approach encryption
and decryption of sensitive data, you may want to consider
how you plan to manage the encryption keys before you go
down this path.
It sounds like you are establishing the foundation of a class
library for a large financial organization. Not having an
enterprise-class key-management system can prove to be their
downfall, no matter how efficiently you encrypt/decrypt data.
I would encourage you to look at an effort at OASIS that is
standardizing on a Symmetric Key Services Markup Language
(SKSML) for acquiring key-management services from an
Enterprise Key Management Infrastructure (EKMI):
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ekmi
Not only does this Technical Committee have the support of
Visa, the US Dept. of Defense, Wells Fargo, Red Hat and 28
other companies/individuals, this schema is also going to be
supported by the IEEE 1619.3 Working Group that is creating
a key-management protocol for storage devices (see the list
of Announcements on the OASIS web-page for how they will
integrate to an EKMI).
An open-source implementation of SKSML is available at
http://www.strongkey.org with an example application that
shows column-level encryption of - interestingly - credit
card numbers in an RDBMS.
The open-source implementation is based on Java; if you need
C/C++, you can either choose to create your own client library
that implements SKSML (and use the open-source SKMS for the
server) or contact me privately for an alternative solution.
Arshad Noor
StrongAuth, Inc.
[EMAIL PROTECTED] wrote:
So... supposing I was going to design a crypto library for use within
a financial organization, which mostly deals with credit card numbers
and bank accounts, and wanted to create an API for use by developers,
does anyone have any advice on it?
It doesn't have to be terribly complete, but it does have to be
relatively easy to use correctly (i.e. securely).
I was thinking of something like this:
class crypto_api
{
...
// developers call these based on what they're trying to do
// these routines simply call crypto_logic layer
Buffer encrypt_credit_card(Buffer credit_card_number, key_t key);
Buffer encrypt_bank_account(Buffer bank_account, key_t key);
Buffer encrypt_other(Buffer buffer, key_t key);
...
};
class crypto_logic
{
...
algo_default = ALGO_AES256CBC;
// encrypt with a given algorithm
Buffer encrypt(Buffer buffer, key_t key, algo_t aid = algo_default);
// calls different routines in crypto_implementation layer depending on
algorithm used
Buffer decrypt(Buffer buffer, key_t key);
...
};
class crypto_glue
{
...
// calls routines in libraries such as OpenSSL
// mostly wrappers that translate between our data types and theirs
Buffer aes256cbc-encrypt(...);
Buffer aes256cbc-decrypt(...);
...
};
The general idea is that crypto_api provides domain-specific APIs that
are easy for anyone to understand, that the logic layer allows for the
selection of different algorithms, and the glue layer is basically a
translation layer to underlying libraries.
It is very important that the API remain stable, because the code
base is large and owned by various groups.
One thing that I'm wondering is how to indicate (e.g.) the overhead in
terms of padding, or whatever, for various algorithms... or if it
matters. The old code had some really disturbing practices like
assuming that the output buffer was 16 octets bigger, and stuff like
that... scary.
Intend to skim the OpenSSL design and Gutmann's "Design of a
Cryptographic Security Architecture" for ideas.
Comments?
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
