[111114] in cryptography@c2.net mail archive
crypto class design
daemon@ATHENA.MIT.EDU (travis+ml-cryptography@subspacefie)
Tue Dec 18 21:36:12 2007
Date: Mon, 17 Dec 2007 10:38:59 -0600
From: travis+ml-cryptography@subspacefield.org
To: Cryptography <cryptography@metzdowd.com>
Mail-Followup-To: Cryptography <cryptography@metzdowd.com>
--u3/rZRmxL6MmkK24
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
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 =3D ALGO_AES256CBC;
// encrypt with a given algorithm
Buffer encrypt(Buffer buffer, key_t key, algo_t aid =3D 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?
--=20
In God We Trust, All Others Must Provide Source Code
<URL:https://www.subspacefield.org/~travis/> Eff the ineffable!
For a good time on my email blacklist, email john@subspacefield.org.
--u3/rZRmxL6MmkK24
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (OpenBSD)
iQIVAwUBR2amI2QVZZEDJt9HAQKrJxAAhykuhMhX6VMxcZfK5vPwYR8FlPsGo0ei
KLa5iweOtLf2FpL3lz0j5bPfyGn+Ffyl26raQ3Q6BjD4CFF9F62gkB4+FUkd8f24
VQgyRTyDaWnp7hYj/IxZfgis2W9LgT4Os+la16rCwu4lR57Cba8D35CHTITVCnXa
+M/oSvvzq3NPLtecaJZGd2XvGiyPncqrclvZBcl1DnhDsboFfCSWvtnrEnqOqFbW
QEiGQHf2GRLZiWlqh1usYO6F0OdAvv2CxTEyzppYbj3tPIvPG0lKEjNg7hvwFm2Z
tsWYnVhxf3PixCBEwauP0bH/w73CkCThRuhgvpYttRBCueKiuFkjKUgrEPTP3cne
EeObvwJae6uqGXkIWQ9723vDt0d9nxCKJxDi/8WvAQN+X7yWPC4BLp8WZfZvLYB7
Plp3Yva2pvkljgDfHfwsCC0fYphtdHWjyoRk5IvQ78UKuVYQr84Vl0YtBvNOVI7h
z7xBwXoHCgiUC60yBAKtTzHK2CF+CWxhrtysxPQJIHgWmYXW4vpO0h559hxm8e44
fYLGsHu5u+BnHL7i8pnffIBpsKZYVVIZe7YR6peSZwO8ZaSNGODTgaJWIk/gViPF
ivbUgUeD6Tx+0iv8dXxSnwWEPnnFgjHRMwonXbJkfefmK5wIszFZa9sGCgySWQSJ
GyJTNrIdDv0=
=1JR5
-----END PGP SIGNATURE-----
--u3/rZRmxL6MmkK24--
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
