| 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,
On Dec 17, 2007, at 17:38, [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
On Mon, Dec 17, 2007 at 10:38:59AM -0600, [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 h
> 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.
I
In my experience of doing security evaluations for large financial
institutions in AsiaPac, I suspect the biggest problem you'll face in
doing this is hubris from the app developers. I don't know why, but
these guys so often have a problem taking advice, at least in my
experience (which now covers
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.
