Re: Digital signatures have a big problem with meaning
Rich Salz [EMAIL PROTECTED] writes: Peter's shared earlier drafts with me, and we've exchanged email about this. The only complaint that has a factual basis is this: I don't want to have to implement XML processing to do XML Digital Signatures I don't want to have to re-implement Apache in order to do an SSL implementation. I don't want to have to re-implement MS Exchange in order to do a PGP implementation. I don't want to have to re-implement ext2fs in order to encrypt a file. Makes sense to me. The other problem with XML sigs (also pointed out in the writeup) is the fact that it gives you 10 ways to do everything, of which only 1 is actually correct/secure/usable, but is indistinguishable from the other 9. Since ease of use/secure-by-default is a major goal of my work, I'm rather reluctant to implement something that lets users blow their feet off in a dozen different ways without even knowing it. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Digital signatures have a big problem with meaning
I don't want to have to re-implement Apache in order to do an SSL implementation. ... Those analogies aren't apt. XML is a data format, so it's more like I don't want to have to implement ASN1/DER to do S/MIME Which is a nonsensical complaint. Makes sense to me. The other problem with XML sigs (also pointed out in the writeup) is the fact that it gives you 10 ways to do everything, of which only 1 is actually correct/secure/usable, but is indistinguishable from the other 9. I don't see it. Yes, XML DSIG makes it possible to sign parts of an XML document. And there are broken applications. Er, so what? Is the lack of certificate validation in outlook proof that S/MIME is broken? reluctant to implement something that lets users blow their feet off in a dozen different ways without even knowing it. So have your API take an XML document and output a signature that signs the exclusive canonicalization of that document, and includes the signer's certificate in the keydata. Problem solved. And that's a fair comparison, since S/MIME is just a profile of PKCS#7 applied to email, right? So use WS-Security which is a profile of XML DSIG applied to SOAP messages, for example. In other postings, you've pointed out that nobody re-generates the DER, but instead keeps it around to verify the signature. In the XML world we do it all the time; recreating and re-canonicalizing works. I guess that proves S/MIME and PGP are fundamentally broken. :) /r$ -- Rich Salz, Chief Security Architect DataPower Technology http://www.datapower.com XS40 XML Security Gateway http://www.datapower.com/products/xs40.html - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: encrypted tapes (was Re: Papers about Algorithm hiding ?)
[EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: | Oracle, for example, provides encryption functions, but the real problem | is the key handling (how to make sure the DBA can't get the key, cannot | call functions that decrypt the data, key not copied with the backup, | etc.). | There are several solutions for the key management, but the vendors should | start offering them. I would argue that the real problem is that encryption slows large searches (is percieved to slow large searches, anyway.) Adam Yes, encrypting indexed columns for example is a problem. But if you limit yourself to encrypting sensitive information (I'm talking about stuff like SIN, bank account numbers, data that serves as an index to external databases and are sensitive with respect to identity theft), these sensitive information should not be the bases of searches. If they are not he basis of searches, there will be no performance problems related to encrypting them. If they are indexes to external databases, then they are the basis of searches in those databases, by definition. My terminology might have been misleading. By indexes to external databases, I don't mean that the application that uses the database actually talks to the external databases (it doesn't use the info as a key to that external database) . Example: Cash_Ur_check is in the business of cashing checks. To cash a check, they ask you for sensitive information like SIN, bank account number, drivers licence number, etc. They use the information to query Equifax or the like to see if the person has a good credit rating, if the rating is o.k. they cash the check. They keep all the information in the database, because if the client comes back 2 months later, they will send the same query to Equifax to see if the credit rating hasn't changed. These sensitive information are indexes to external databases (but Cash_Ur_check doesn't directly connect to these other databases). Cash_Ur_check doesn't need to use these data as indexes. Cash_Ur_check can use first/middle/last name of person as an index, or attribute some random number to the person, or something else, they should not use the SIN to identify a person. They should not do searches on SIN to find a person given his SIN. Sure, but Equifax should. I have many other examples in mind, which I came across in the real world. So my answer to people that have the perception you mentioned is that if you want to encrypt sensitive information and that would cause performance problems, then there are problems with your data architecture privacy wise (you should re-structure your data, use it differently, etc.). Not a very satisfactory answer. No, of course I would sit down with the client and the software developers and examine their needs and constraints suggest how they can structure their data in a better way. I've done it several times over the years. There is no universal answer, but in my experience I found there is often good solutions. Let me throw back a precise question to you, to see if you disagree with what I said. Are you saying that it is often inevitable to index sensitive data? That is, are you saying that you often have to use sensitive data as the basis of searches? Yes. -- ApacheCon Europe http://www.apachecon.com/ http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: encrypted tapes (was Re: Papers about Algorithm hiding ?)
Ben Laurie wrote [EMAIL PROTECTED] wrote: Example: Cash_Ur_check is in the business of cashing checks. To cash a check, they ask you for sensitive information like SIN, bank account number, drivers licence number, etc. They use the information to query Equifax or the like to see if the person has a good credit rating, if the rating is o.k. they cash the check. They keep all the information in the database, because if the client comes back 2 months later, they will send the same query to Equifax to see if the credit rating hasn't changed. These sensitive information are indexes to external databases (but Cash_Ur_check doesn't directly connect to these other databases). Cash_Ur_check doesn't need to use these data as indexes. Cash_Ur_check can use first/middle/last name of person as an index, or attribute some random number to the person, or something else, they should not use the SIN to identify a person. They should not do searches on SIN to find a person given his SIN. Sure, but Equifax should. No, they shouldn't! If you think they should, you are missinformed. At least in Canada, the Privacy Act protects the SIN, Equifax cannot demand it. See for example http://www.privcom.gc.ca/fs-fi/02_05_d_02_e.asp and http://www.guardmycreditfile.org/index.php/content/view/244/139/ which says the following: Even credit reporting companies cant demand a SIN to generate a credit report. Trans Union Canada and Equifax Canada both have the ability to generate such reports without a SIN. If you ask these same companies to generate a credit report in the United States, they both require a Social Security Number. And if Equifax Canada can generate reports without a SIN, I don't see why Equifax in any other country couldn't. Of course, they like to have the SIN, since it makes things more convenient, but they don't really need it! That is the problem in most cases. --Anton - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: encrypted tapes (was Re: Papers about Algorithm hiding ?)
[EMAIL PROTECTED] wrote: Ben Laurie wrote [EMAIL PROTECTED] wrote: Example: Cash_Ur_check is in the business of cashing checks. To cash a check, they ask you for sensitive information like SIN, bank account number, drivers licence number, etc. They use the information to query Equifax or the like to see if the person has a good credit rating, if the rating is o.k. they cash the check. They keep all the information in the database, because if the client comes back 2 months later, they will send the same query to Equifax to see if the credit rating hasn't changed. These sensitive information are indexes to external databases (but Cash_Ur_check doesn't directly connect to these other databases). Cash_Ur_check doesn't need to use these data as indexes. Cash_Ur_check can use first/middle/last name of person as an index, or attribute some random number to the person, or something else, they should not use the SIN to identify a person. They should not do searches on SIN to find a person given his SIN. Sure, but Equifax should. No, they shouldn't! If you think they should, you are missinformed. At least in Canada, the Privacy Act protects the SIN, Equifax cannot demand it. I am just reading what you've written: To cash a check, they ask you for sensitive information like SIN, bank account number, drivers licence number, etc. They use the information to query Equifax or the like -- ApacheCon Europe http://www.apachecon.com/ http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: encrypted tapes (was Re: Papers about Algorithm hiding ?)
On Fri, Jun 10, 2005 at 01:11:45PM -0400, [EMAIL PROTECTED] wrote: | Ben Laurie wrote | Sure, but Equifax should. | | No, they shouldn't! If you think they should, you are missinformed. At | least in Canada, the Privacy Act protects the SIN, Equifax cannot demand | it. | See for example | http://www.privcom.gc.ca/fs-fi/02_05_d_02_e.asp | and | http://www.guardmycreditfile.org/index.php/content/view/244/139/ | which says the following: | Even credit reporting companies cant demand a SIN to generate a credit | report. Trans Union Canada and Equifax Canada both have the ability to | generate such reports without a SIN. If you ask these same companies to | generate a credit report in the United States, they both require a Social | Security Number. | | And if Equifax Canada can generate reports without a SIN, I don't see why | Equifax in any other country couldn't. Of course, they like to have the | SIN, since it makes things more convenient, but they don't really need it! | That is the problem in most cases. Actually, there's a difference between theory and practice here. When I signed up for a mobile phone, they demanded a SIN, or would put me on the sucker plan. When I complained to the Quebec privacy commissioner, they told me that that was OK. There are so many examples of this sort of thing that I gave up sending complaint letters. Then you look at CIBC, and the lack of fines... Adam - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: encrypted tapes (was Re: Papers about Algorithm hiding ?)
[EMAIL PROTECTED] wrote: Ben Laurie wrote [EMAIL PROTECTED] wrote: Example: Cash_Ur_check is in the business of cashing checks. To cash a check, they ask you for sensitive information like SIN, bank account number, drivers licence number, etc. They use the information to query Equifax or the like to see if the person has a good credit rating, if the rating is o.k. they cash the check. They keep all the information in the database, because if the client comes back 2 months later, they will send the same query to Equifax to see if the credit rating hasn't changed. These sensitive information are indexes to external databases (but Cash_Ur_check doesn't directly connect to these other databases). Cash_Ur_check doesn't need to use these data as indexes. Cash_Ur_check can use first/middle/last name of person as an index, or attribute some random number to the person, or something else, they should not use the SIN to identify a person. They should not do searches on SIN to find a person given his SIN. Sure, but Equifax should. No, they shouldn't! If you think they should, you are missinformed. At least in Canada, the Privacy Act protects the SIN, Equifax cannot demand it. I am just reading what you've written: To cash a check, they ask you for sensitive information like SIN, bank account number, drivers licence number, etc. They use the information to query Equifax or the like They'll ask for it, but you don't have to give it. They can collect it, but they don't have to do searches on it. It's the typical ask for SIN if the user gives it use it (as in Adam Shostack's example with cell phone), but if they don't then ask for 2 other identity cards. In most cases, I don't have to give my SIN, but almost everybody asks for it. Equifax will always ask for the SIN but they don't have the right to demand it. http://www.piac.ca/newpage91.htm Equifax suggests that to prevent these inaccuracies, consumers should always give their full name and SIN number on application forms (this facilitates updating of files and prevents confusion of two files). However, this solution to the problem does not take into account that consumers have a valid interest in protecting their privacy with respect to their SIN. The problem is with forms that make it look like you have to give your SIN, when in fact the law says you don't have to. Providing other identification can be troublesome, so allot of people just end up giving their SIN. --Anton - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: encrypted tapes
On 6/8/05, [EMAIL PROTECTED] (Perry E. Metzger) wrote: -+-- | If you have no other choice, pick keys for the next five years, | changing every six months, print them on a piece of paper, and put it | in several safe deposit boxes. Hardcode the keys in the backup | scripts. When your building burns to the ground, you can get the tapes | back from Iron Mountain and the keys from the safe deposit box. | Assuming I even understand the problem, this is, in fact, one of the wonderful uses of split-key (threshold) crypto; including scale-down to the individual desktop. split K as 2-of-3 quorum (1) smartcard (2) laptop (3) corp server encrypt disk using K (or another key protected by K, of course) situations handled (a) Dan offline inside Faraday cage, use frags 1,2 to do work (b) fire Dan / confiscate laptop, use frags 2,3 to read disk (c) Dan leaves laptop in cab, use frags 1,3 to recover from backup We can (for backup tapes) make 2-of-N splits. This would allow each tape of a multi-volume tape set to be partially encrypted in a different fragment which nevertheless could have its encryption completed by the common fragment held centrally thus making each tape a different cryptanalysis problem for the attacker but without the apparent key management overhead for the good guys. As one fragment of a quorum can be set in advance, that fragment could be common to several otherwise non-communicating sets of tapes and thus be the one retained in that central, good-guy location. And so forth. Disclaimer: I am a good enough mathematician to know how bad a mathematician I really am so, in the usual Internet practice, a flood corrections/denunciations will doubtless now commence. --dan ref: Geer DE Yung M : Threshold Cryptography for the Masses, Proceedings, Sixth International Financial Cryptography Conference, Southampton, Bermuda, 11-14 March 2002. http://geer.tinho.net/geer.yung.PDF - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: analysis of the Witty worm
In message [EMAIL PROTECTED], Jerrold Leichter writes: | | The paper itself (there's a link in the article) has several more items | | of interest to this list. Especially interesting is the effective | | cryptanalysis of the PRNG used by the worm. Implicit in many of the | | analyses, though not a focus of the paper, is the amount of information | | that the authors could gather about network configurations at different | | sites: as we all know, traffic analysis is a powerful technique. | The links in the paper no longer work - they go to restricted pages. The | (or an) HTML version is in the Google cache at: | | http://64.233.161.104/search?q=cache:oS94i-ojvIgJ:www.cc.gatech.edu/~akumar/ witty.html+witty+worm+analysis+paxsonhl=enstart=1 Oops. I should have read it more closely first. The only thing in Google's cache is the intro page, with an abstract. The paper (pdf and ps) and a slide show are inaccessible, and are not in Google's cache. Anyone saved a copy? It's on Vern's web page: http://www.icir.org/vern/papers/witty-draft.pdf or http://www.icir.org/vern/papers/witty-draft.ps --Steven M. Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: de-identification
I'd like to come up to speed on the state of the art in de-identification (~=anonymization) of data especially monitoring data (firewall/hids logs, say). We call it pseudonymization (Pseudonymisierung). It's a commonly used technique in Germany to detaint personally identifiable information, so you can share it freely for statistics purposes. The methods used in the field are rather crude (time-seeded LCGs are very common, unfortunately). A reference to the book Translucent Databases was posted to this list a couple of months ago, but IIRC it's being revisied, so I didn't rush to buy and read it. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
[ANNOUNCE] OpenSSL 0.9.8 beta 5 released
OpenSSL version 0.9.8 Beta 5 OpenSSL - The Open Source toolkit for SSL/TLS http://www.openssl.org/ OpenSSL is currently in a release cycle. The fifth beta is now released. The beta release is available for download via HTTP and FTP from the following master locations (the various FTP mirrors you can find under http://www.openssl.org/source/mirror.html): o http://www.openssl.org/source/ o ftp://ftp.openssl.org/source/ The file names of the beta are: o openssl-0.9.8-beta5.tar.gz MD5 checksum: 4b492a622ca39f0c444c3cabc330933d SHA1 checksum: 3524b04490491e1d1674363fac601cd4b002d471 The checksums were calculated using the following command: openssl md5 openssl-0.9.8-beta5.tar.gz openssl sha1 openssl-0.9.8-beta5.tar.gz Please download and test them as soon as possible. This new OpenSSL version incorporates 104 documented changes and bugfixes to the toolkit (for a complete list see http://www.openssl.org/source/exp/CHANGES and http://www.openssl.org/source/exp/NEWS). Since the fourth beta, the following has happened: - Changed -m486 to -march=i486 in Configure. - Added a new NetWare target that uses BSD sockets. - Propagate INSTALL_PREFIX to inner Makefiles. - Make it possible to read files larger than 2GB with the FILE BIO. - Enhance cipher suite parsing. - Other bug fixes... Reports and patches should be sent to [EMAIL PROTECTED] Discussions around the development of OpenSSL should be sent to [EMAIL PROTECTED] Anything else should go to [EMAIL PROTECTED] The best way, at least on Unix, to create a report is to do the following after configuration: make report That will do a few basic checks of the compiler and bc, then build and run the tests. The result will appear on screen and in the file testlog. Please read the report before sending it to us. There may be problems that we can't solve for you, like missing programs. Yours, The OpenSSL Project Team... Mark J. Cox Nils Larsch Ulf Möller Ralf S. Engelschall Ben Laurie Andy Polyakov Dr. Stephen Henson Richard Levitte Geoff Thorpe Lutz JänickeBodo Möller - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Collisions for hash functions: how to exlain them to your boss
Stefan Lucks [EMAIL PROTECTED] writes: Magnus Daum and myself have generated MD5-collisons for PostScript files: http://th.informatik.uni-mannheim.de/people/lucks/HashCollisions/ This work is somewhat similar to the work from Mikle and Kaminsky, except that our colliding files are not executables, but real documents. We hope to demonstrate how serious hash function collisions should be taken -- even for people without much technical background. And to help you, to explain these issues - to your boss or your management, - to your customers, - to your children ... While this is a clever idea, I'm not sure that it means what you imply it means. The primary thing that makes your attack work is that the victim is signing a program which he is only able to observe mediated through his viewer. But once you're willing to do that, you've got a problem even in the absence of collisions, because it's easy to write a program which shows different users different content even if you without hash collisions. You just need to be able to write conditionals. For more, including an example, see: http://www.educatedguesswork.org/movabletype/archives/2005/06/md5_collisions.html -Ekr - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: de-identification
Florian Weimer wrote: We call it pseudonymization (Pseudonymisierung). It's a commonly used technique in Germany to detaint personally identifiable information, so you can share it freely for statistics purposes. The methods used in the field are rather crude (time-seeded LCGs are very common, unfortunately). from privacy glossary and taxonomy http://www.garlic.com/~lynn/privacy.htm that i put together when working on x9.99 PIA standard for financial industry ... from HIPAA anonymized Previously identifiable data that have been deidentified and for which a code or other link no longer exists. An investigator would not be able to link anonymized information back to a specific individual. [HIPAA] (see also anonymous, coded, directly identifiable, indirectly identifiable) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: expanding a password into many keys
From: Ian G [EMAIL PROTECTED] Sent: Jun 12, 2005 11:27 AM To: cryptography@metzdowd.com Subject: expanding a password into many keys I'd like to take a password and expand it into several keys. It seems like a fairly simple operation of hashing the concatonatonation of the password with each key name in turn to get each key. Are there any 'gotchas' with that? There's a length extension property with what you're doing, so if I get to choose your key names, I can do something unpleasant to you. Suppose I know the length of pass, and get to choose two key names, K1_name and K2_name. You give me K1 = sha1( pass||K1_name), then I need to guess K2_name. I can choose K2_name to be K1_name, appropriately padded to the full block size exactly as it will be in the SHA1 computation that produces K1. Then, I can compute K2 on my own, because the only effect of the secret value pass on K2 is going through K1. This doesn't look like an especially realistic attack model, but I'm not sure what you're doing with this iang --John Kelsey - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
encrypted backup tapes
Back when software was free, ~1974, the standard DEC PDP10 disk-tape backup program, FRS, included an encryption option. Rich Schroeppel [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Collisions for hash functions: how to exlain them to your boss
Hi Eric, Technically speaking you're correct, they're signing a program. But most people, certainly non-techies like Alice's boss, view postscript (or MS Word, or name your favourite document format that allows macros) files not as programs but as static data. In being targeted at non-techies I find this attack more convincing than those of Mikle and Kaminsky, though essentially it's a very similar idea. Note that opening the postscript files in an ASCII-editor (or HEX-editor) immediately reveals the attack. Stefan Lucks told me they might be able to obfuscate the postscript code, but again this will only fool the superficial auditor. Grtz, Benne = Technische Universiteit Eindhoven Coding Crypto Groep Faculteit Wiskunde en Informatica Den Dolech 2 Postbus 513 5600 MB Eindhoven kamer HG 9.84 tel. (040) 247 2704, bgg 5141 e-mail: [EMAIL PROTECTED] www: http://www.win.tue.nl/~bdeweger = -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eric Rescorla Sent: maandag 13 juni 2005 17:05 To: Stefan Lucks Cc: cryptography@metzdowd.com Subject: Re: Collisions for hash functions: how to exlain them to your boss Stefan Lucks [EMAIL PROTECTED] writes: Magnus Daum and myself have generated MD5-collisons for PostScript files: http://th.informatik.uni-mannheim.de/people/lucks/HashCollisions/ This work is somewhat similar to the work from Mikle and Kaminsky, except that our colliding files are not executables, but real documents. We hope to demonstrate how serious hash function collisions should be taken -- even for people without much technical background. And to help you, to explain these issues - to your boss or your management, - to your customers, - to your children ... While this is a clever idea, I'm not sure that it means what you imply it means. The primary thing that makes your attack work is that the victim is signing a program which he is only able to observe mediated through his viewer. But once you're willing to do that, you've got a problem even in the absence of collisions, because it's easy to write a program which shows different users different content even if you without hash collisions. You just need to be able to write conditionals. For more, including an example, see: http://www.educatedguesswork.org/movabletype/archives/2005/06/ md5_collisions.html -Ekr - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Collisions for hash functions: how to exlain them to your boss
Weger, B.M.M. de [EMAIL PROTECTED] writes: Technically speaking you're correct, they're signing a program. But most people, certainly non-techies like Alice's boss, view postscript (or MS Word, or name your favourite document format that allows macros) files not as programs but as static data. In being targeted at non-techies I find this attack more convincing than those of Mikle and Kaminsky, though essentially it's a very similar idea. Note that opening the postscript files in an ASCII-editor (or HEX-editor) immediately reveals the attack. Stefan Lucks told me they might be able to obfuscate the postscript code, but again this will only fool the superficial auditor. Yes, this is all true, but it's kind of orthogonal to my point, which is that if you're willing to execute a program, this attack can be mounted *without* the ability to produce hash collisions. The fact that so few people regard PS, HTML, Word, etc. as software just makes this point that much sharper. As far as I can tell, the ability fo produce hash collisions just makes the attack marginally worse. -Ekr - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: expanding a password into many keys
On 6/12/05, Ian G [EMAIL PROTECTED] wrote: I'd like to take a password and expand it into several keys. It seems like a fairly simple operation of hashing the concatonatonation of the password with each key name in turn to get each key. Are there any 'gotchas' with that? iang I guess you should use some scheme like PKCS #5 PBKDF2 scheme (password based key derivation function). The only difference between your idea and PBKDF2 is that the latter does a lot of hash rounds and is salted (I guess you pick key name to be static and not random, so they are not used as salts). Salting helps a bit against static precomputed hashes and techniques like rainbow tables. Ondrej Mikle - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: expanding a password into many keys
Ian,
You need to go beyond the scope of simple-minded PKCS recommendations
to calculate keys from passwords. If you want to improve security,
just adding padding and salt is not enough.
Yes, of course, your code should add padding, so that the sha1 argument
always has the same, fixed, length for any password and key name.
Further, as you know, passwords (especially if chosen by a user)
have low entropy... let's say 10 ~ 40 bits. Key names (constrained
by natural language) should also have low entropy per character.
The end result is that a dictionary attack could be quite easy to do,
if you are not careful on several fronts. You need to:
- define your threat model;
- warn users about bad passwords (not all bad pwds can be detected!);
- prevent really bad passwords from being used (ditto);
- prevent easy key names (ditto);
- estimate minimum lengths for passwords AND key names as a function
of all the above -- including the threat model;
- provide for key management, with revocation, expiration and roll-over,
before you face these needs without planning.
Cheers,
Ed Gerck
Ian G wrote:
I'd like to take a password and expand it into
several keys. It seems like a fairly simple operation
of hashing the concatonatonation of the password
with each key name in turn to get each key.
Are there any 'gotchas' with that?
iang
PS: some psuedo code if the above is not clear.
for k in {set of keys needed}
do
key[k] = sha1( pass | k );
done
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: expanding a password into many keys
Ian G wrote: I'd like to take a password and expand it into several keys. It seems like a fairly simple operation of hashing the concatonatonation of the password with each key name in turn to get each key. there is financial standard for derived key per transaction from x9f taxonomy and glossary http://www.garlic.com/~lynn/x9f.htm derived unique key per transaction (DUKPT) A key management method which uses a unique key for each transaction, and prevents the disclosure of any past key used by the transaction originating TRSM. The unique Transaction Keys are derived from a base derivation key using only non-secret data transmitted as part of each transaction. [X924] (see also cryptographic key, transaction) basically you may be able to brute force an individual key w/o comprimising the master key (or any other keys derived from the master key). derived keys are used in other infrastructures beside financial transactions. some token based systems may simply use derived key per token (as opposed to per transaction) ... brute force of a particular token's key doesn't compromise either the overall infrastructure and/or other tokens in the infrastructure. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: encrypted tapes (was Re: Papers about Algorithm hiding ?)
Jerrold Leichter [EMAIL PROTECTED] writes: They also sold a full solution for encrypted Ethernet - KDC, encrypting Ethernet adapters, associated software. None of this stuff went anywhere. People just weren't interested. That wasn't quite the case for the Ethernet encryption. What happened there was that they had a complete product ready to ship and quite a bit of interest when it was killed by marketing. The problem was that Ethernet at the time wasn't the forgone conclusion it is now, it was just one of a number of potential candidates for the foregone-conclusion role. By shipping an encrypting Ethernet adapter, marketing felt that DEC were saying that standard Ethernet wasn't safe. In contrast token ring didn't have an encryption adapter, so obviously token ring must be secure by default, whereas Ethernet clearly wasn't. As a result, the encryption adapter was never shipped. Strategy is not letting the enemy know you're out of bullets by continuing to fire. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
