| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Wed Nov 23 19:57:23 2005 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks@...edu) Subject: SmartCards programming... On Wed, 23 Nov 2005 09:41:46 +0100, khaalel said: (Others have provided pointers to info on smart cards, so I'm going to make some comments about the difference between "using a smart card" and "actual security"...) > The goal is to write the programs and all the associated stuff... in order > to create a DRM-like system: when an user enter his card, a software check > his key (or certificate or...) and if the authentication succeed, the > wanted file (document, video, audio...) is open by the software... The tough part here is figuring out how to have the software open the file, but ensure that the contents are in fact inaccessible without the smart card. In particular, securely handling the data after opening to ensure that the data can't be saved in an unencrypted form is fiendishly difficult, as every single DRM scheme to date has demonstrated.... > have to learn? Which type of smart cards I have to buy? Which algorithms I > can use (DES, RSA, Elliptic Curves, AES...)?? With the exception of single-DES, which is known to be weak for today's hardware (triple-DES still has quite some lifetime, at least for not-too-sensitive data - it's fine for securing a track on a music CD, but maybe not for a nuclear missle launch code), the algorithm used really doesn't matter. There's only 3 basic things you actually need to get right: 1) Choosing symmetric or public-key. 2) Choosing a key/data length large enough to make a brute force attack not worth it (again, this depends on the value of the data being secured). 3) Key management - more actual implementations manage to get this wrong than do the actual crypto wrong. You can do the crypto in a totally secure manner, but it's still total security manure suitable for fertilizing the flower garden if a keystroke logger can easily sniff the passphrase.... All the rest is details and engineering choices (speed versus power consumption, and so on).... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20051123/05548ec8/attachment.bin
Powered by blists - more mailing lists