Security, Cryptography and Privacy Track in PODC 2003: Tutorials and (updated) CFP
Dear Colleagues, Please note that the deadline for submitting to PODC 2003, and in particular to the special track on Security in Distributed Computing, is rapidly approaching - Jan 31, 2003. This event is an excellent opportunity for interaction between the security, cryptography and distributed computing communities, and I hope many of you will send excellent submissions and of course participate. PODC will be held on Sunday July 13th - Wednesday July 16th, 2003, in Boston, Massachusetts. The registration fee includes two interesting pre-conference tutorials on Sunday, July 13. Both are on very active areas in security in distributed computing: Incentives and Internet Computation by Joan Feigenbaum and Scott Shenker, and Content Protection Technologies by Jeffrey B. Lotspiech, Tushar Chandra, and Donald E. Leake Jr.. Abstracts are included below, and can also be found, with bios of the speakers, from the webpage: http://www.podc.org/podc2003 Expect lively discussion on these and other issues related to security and privacy in distributed systems, following these tutorials, as well as our very special invited speakers on security: Ross Anderson (U. of Cambridge), Butler Lampson (Microsoft), and Silvio Micali (MIT), all of which are known for their sometimes conflicting but always interesting views. This year, PODC will also feature a series of lectures illustrating and celebrating the impact of the work of Michael Fischer, in honor of his sixtieth birthday, by: Leslie Lamport, Microsoft, Nancy Lynch, MIT, Albert Meyer, MIT, and Rebecca Wright, Stevens Inst. of Tech.. Topics are not announced yet but considering the speakers, I am sure these presentations will also be of interest to crypto/security folks. So, please participate and submit and encourage others to do so; e.g. please post the CFP in relevant forums. PODC especially encourages student participation, and a prize will be given to the best student paper; we may be able also to partially sponsor some of the students participating and presenting, depending on budget. PODC'03 received generous support from Microsoft and Sun Microsystems. If you are interested in making additional contributions, possibly for sponsoring a specific purpose, please contact the general chair, Elizabeth Borowsky, [EMAIL PROTECTED] (Boston College). Looking forward to your submissions and to see you in PODC 2003! Amir Herzberg http://amir.herzberg.name Content Protection Technologies Jeffrey B. Lotspiech, Tushar Chandra, Donald E. Leake Jr. Abstract The entertainment industry is in the midst of a digital revolution, the growth of which seems only limited by concerns about the unauthorized redistribution of perfect copies that digital technology enables. Several content protection technologies have been deployed already in consumer electronic devices, and more are in the works. In the near future, the average person's encounter with cryptography will not be restricted to access to ATM machines, but will include his TV, his stereo, and his home entertainment network. We trace the history of digital content protection technologies, starting with Copy Generation Management System found on Digital Audio Tape, to the Content Scrambling System used on DVD video, and moving on to more cryptographically sound technologies like Digital Transmission Content Protection used on the IEEE digital 1394 bus, and Content Protection for Recordable Media used on DVD Audio, DVD video recorders, and the Secure Digital Memory Card. It turns out that the relatively new area of cryptography called broadcast encryption has found an enthusiastic acceptance in content protection applications. In fact, the content protection application has inspired recent theoretical advances in this area. One newly-defined problem in content protection is called authorized domains. The idea is that the consumer's extended home becomes a domain in which content can be copied and moved without restriction. The consumer only encounters technical obstacles when he/she tries to widely redistribute the copyrighted content. This requires that the entertainment devices in the home, which may be only intermittently connected, act as a distributed system to agree upon common cryptographic keys. Although public-key systems can provide this function, it turns out that broadcast encryption can also work in this application, and has some intriguing advantages. However, not all content protection is based on cryptography. We discuss signal-processing based technologies like MacroVision and digital watermarking. Our view is that cryptography and signal-based technologies are not competitors, but instead complement each other. Cryptographic solutions should dominate while the content remains in the digital domain. Once the content is rendered in analogue form for viewing or listening, signal processing takes over, to provide the last line of defense. As technologists we would
RE: 'E-postmark' gives stamp of approval
Cryptographically, the solution they (AuthentiDate) offer is basic: timestamping and authentication (non-repudiated origin identification) by a single trusted authority (USPO). I hope it's well implemented and that it would succeed; it can definitely provide a substantial advantage over current e-mail... I don't think it can help much as solution against spamming, by itself: people will use timestamped mail only when needed, which means you can't filter out all non-timestamped mail. Of course it could help as a mechanisms to filter out new correspondants, if used together with appropriate mechanism for identifying known recipients, which seems to me the right way to handle spam. Two points worth imporving: 1. Their scheme uses a single authority. It would be better to allow use of multiple authorities for reliability, security, and competition (Ok, maybe AuthentiDate as a company prefers to have only one service...) 2. They offer only non-repudiation of origin; it's a pity they don't offer also non-repudiation of submission, this could be really useful certified-mail feature for B2B. The protocols required are not much more complex (see e.g. my recent work http://eprint.iacr.org/2002/084/). Regards, Amir Herzberg http://amir.herzberg.name -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of R. A. Hettinga Sent: Wednesday, November 27, 2002 5:07 PM To: Digital Bearer Settlement List; [EMAIL PROTECTED] Subject: 'E-postmark' gives stamp of approval http://seattletimes.nwsource.com/cgi-bin/PrintStory.pl?document_id=3D134580416zsection_id=3D268448455slug=3Dcomdex21date=3D20021121 ... - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Extracting unifrom randomness from noisy source
Hi all, I've looked into this a bit further, and here is summary. 1. In order to extract randomness from an arbitrary noisy source, we need to use some short, `seed` random string. We assume that the noise is independent of this `seed`. (If we don't use a seed, then every randomness extracting (deterministic) function has some distribution of input (noise) for which the output is not uniformly distributed - e.g. any distribution of inputs which map to one output...) 2. Of course, the `seed` requirement does not apply if we hash the noise using a hash function, and analyse using the `random oracle` model i.e. analyse security when the hash function is implemented by a randomly choosen function. But clearly here the randomness is `hidden` in the `choice` of the random function. Clearly this is not a good justification for relying on any particular hash function (e.g. SHA1)! 3. I don't know of any attack showing a reasonable, natural source of noise for which the output of some reasonable hash function is non-uniformly distributed. However I'm also not aware of any cryptoanalytical effort to demonstrate such an attack. While almost all practical crypto is based on unproven assumptions and `proof of security by failure of cryptoanalysis`, seems that simply relying on SHA1(noise) to be uniform is hardly justifyable. 4. There is substantial amount of research showing efficient randomness extractors. Noam Nisan has a nice survey, available from his homepage, N. Nisan. Extracting randomness: How and why (a survey). In Proceedings of the 11th IEEE Conference on Computational Complexity, pages 44--58. IEEE, New York, 1996. 5. While the extractors described by Nisan (and others) are indeed very efficient, I'm not aware of any available implementations. Implementors may consider using therefore their favorite block cipher, e.g. AES, using a random key. Notice that this random key should be selected uniformly but could be part of the software, common to all deployments and non-secret; security is only based on the independence of the sampled noise in this key. Namely, pseudo-random = AES_k (noise) Security of this construction follows from the assumption that the block cipher (e.g. AES) is a Pseudo-random function; notice that this is a standard assumption for block ciphers (and therefore block ciphers are cryptoanalysed to meet this assumption). 6. Of course under the random oracle model, h(x,k) is also a pseudo-random function... But why? Regards, Amir Herzberg See http://amir.herzberg.name/book.html for lectures and draft-chapters from book-in-progress, `Introduction to Cryptography, Secure Communication and Commerce`; feedback appreciated! - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: building a true RNG
David Wagner said, The problem can really be divided into two parts: 1. Is our entropy crunching algorithm secure when used with a random oracle instead of SHA1? 2. Does SHA1 behave enough like a random oracle that the answer to question 1. is in any way relevant to the real world? I suspect that question 1. is not hard to answer in a formal, rigorous, provable way. It is only question 2. that is hard to answer. It is absolutely true that we have no proof for question 2. That said, we should keep in mind that none of our cryptographic algorithms (even 3DES) come with a proof of security. All we have to rest on is years of unsuccessful cryptanalysis. But there's a big difference: the random oracle `assumption` is clearly not valid for SHA-1 (or any other specific hash function). Since this is trivial, it is less clear what is the cryptoanalytical problem that SHA1 was tested for. SHA-1 (and similar functions) were tested mainly for collision-resistance (and also for one-wayness). But clearly these properties are not sufficient for the proposed use (to extract entropy). So the question is again: what is an assumption which we can test SHA-1 against, and which is sufficient to make the `entropy crunching alg` secure? I found that when trying to explain and define hash functions and their properties, I didn't find a satisfactory definition for the `randomness` properties. Best Regards, Amir Herzberg See http://amir.herzberg.name/book.html for lectures and draft-chapters from book-in-progress, `Introduction to Cryptography, Secure Communication and Commerce`; feedback appreciated! - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: building a true RNG
In several posts to the list, e.g. by Wagner and Denker, it is proposed to use a `strong crypto hash function` h(), e.g. SHA1, to extract entropy from a physical source, i.e. + Source -- Digitizer -- good hash Namely, if the sample from the digitizer (of the physical source) is x, the suggestion is to use h(x) as random data. I think this is a very common design in practice. But clearly this relies on some property of the hash function. For example Denker says: a) if the hash function happens to have a property I call no wasted entropy then... [this h(x) is `as good as random`]. Indeed if we adopt the `random oracle` methodology, i.e. analyze the system assuming h() is a truly random function, then we easily see that h(x) are truly random bits (assuming the number of bits in h(x) is significantly less than the entropy in x). But: the `random oracle` methodology helps us find vulnerabilities in protocols, but no specific hash function is really a random oracle... So I ask: is there a definition of this `no wasted entropy` property, which hash functions can be assumed to have (and tested for), and which ensures the desired extraction of randomness? Regards, Amir Herzberg See http://amir.herzberg.name/book.html for lectures and draft-chapters from book-in-progress, `Introduction to Cryptography, Secure Communication and Commerce`; feedback appreciated! - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Fwd: Re: Quantum Computing Puts Encrypted Messages at Risk
At 20:50 11/07/2002, Ian wrote: When I first read The Code Book (Simon Singh), I drooled endlessly at the idea of Unbreakable Encryption, until I became a little more cynical. I questioned Dr Singh on this when he came and gave a lecture in Cheltenham UK recently, and his best answer was that QKD is so secure because its a different kind of system. Its not like conventional encryption. [synopsis - not direct quotation]. I'm not thorougly convinced. Can anyone (politely) prove this mere outsider wrong? I am also not a physicist. So I share your skepticism about relying for security on physic theories which I don't understand, and furthermore which may evolve and refine over time. However, as many people are excited about Quantum crypto, I really would like to put my skepticism aside and understand what is its cryptographic significance, say if we accept the physics as valid (for ever or at least `long enough`). In particular I'm considering whether I should and can cover this area in my book. I must admit I haven't yet studied this area carefully, so my questions may be naive, if so please excuse me (and your answer will be doubly appreciated). Some questions: 1. Quantum key encryption seems to require huge amounts of truly random bits at both sender and receiver. This seems impractical as (almost) truly random bits are hard to produce (especially at high speeds). Is there a fix? 2. After the transmission, the receiver is supposed to tell the sender how it set its polarization; how is this authenticated? If it isn't we are obviously susceptible to man in the middle attack. 3. It seems the quantum link must connect directly from sender to receiver. How can this help provide end to end security on the Internet? Or are we back to private networks? 4. As to quantum computation signalling the end of `crypto as we know it`... Is it fair to say this may end only the mechanisms built on discrete log and/or factoring, but not shared key algorithms like AES and some of the other public key algorithms? Best, Amir Herzberg Amir Herzberg See http://amir.herzberg.name/book.html for draft chapters from `Introduction to Cryptography, Secure Communication and Commerce`, and link to lectures. Comments appreciated. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: crypto question - using crypto to protect financial transactions
I understand the goal of allowing secure and anonymous financial transactions via the Net. I'm personally very interetested in this, although I must admit I am also a bit concerned about the social implications if this becomes a reality (or when it does, since I believe it eventually will). What I'm concerned about is tax avoidance, esp. by wealthy individuals and companies. Nobody likes taxation (at least personally :-), but it is still the basis for operation of states - and while changes may be good, they are also risky. Anyway, forgetting for a moment the question of should we do it, let's focus on the question of how we do it :-) I looked up Andrew's site, and actually there're not too many details there (yet?). I think his initial focus and question was on the issue of whether one can trust one's public key to the financial server, and his answer seems to be, you can if you split the key between several servers using thershold or proactive signatures (proactive schemes allow recovery from penetrations of servers - and btw, this is an area deserving more implmentation efforts, beyond what we did in IBM). I think there may be even more critical hurdles for successful financial crypto services. A very important one is interoperability between different financial service providers (the companies that keep your money... E.g. banks). Most crypto-financial efforts so far focused on a centralized model - one bank - and that's much easier to design, but very hard to succeed. I've done some work on secure interoperability among providers - it was actually the main feature of IBM Micro Payments. IBM have also applied for patent for some of the ideas. Another important issue is the automated management of trust and reputation, allowing customers to make (automated) trust decisions on providers of services and goods (including both financial services and merchants). Here I agree with Andrew that for many applications, financial transactions should not be reversible (disputed), and hence trust and reputation becomes the main means for consumer protection. Regards, Amir Herzberg See http://amir.beesites.co.il/book.html for lectures and draft-chapters from book-in-progress, `secure communication and commerce using cryptography`; feedback welcome! - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: theory: unconditional security
I suspect you find little written about OTP work because people have always assumed the keys were impractical to distribute, store and use. Another concern with OTP and other unconditionally-secure schemes is that they usually require limited number of applications of the key (usually, use once). This introduces a substantial synchronization / reliability / security problem for many applications. Notice that unconditionally secure authentication and signatures are in fact used in scenarios where the limited use can be easily assured, such as in online/offline signatures, used e.g. for micropayments and for multicast encryption. In these cases, a `regular` offline signature (e.g. RSA) is used to sign in advance (offline) the public key of the one-time signature scheme. The one-time signature is applied when processing online the message to be signed (with very little time). Of course, the reason one-time signatures are used for these applications is because they are faster, not because they are unconditionally secure. Regards, Amir Herzberg See http://amir.beesites.co.il/book.html for lectures and draft-chapters from book-in-progress, `secure communication and commerce using cryptography`; feedback welcome! - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Cringely ...or- long-lasting encryption - motivation for ECC?
Eric Rescola [ER] replied to Eugene Leitl [EL]: ... EL: Personally, I no longer trust RSA for long term security. This is public-key crypto, not symmetric, so a break of your RSA key means that all your encrypted traffic becomes readable rather than just one message. E.g., if a few years ago you used 512-bit RSA to encrypt a will that was not to be read by anybody until you die, that's tough because it could be read today. Doesn't matter that you moved to 768 bits and then 1024 in the meantime. If you care about Perfect Forward Secrecy, you shouldn't be using RSA at all. You should be using DH with a fresh key for each exchange. The probability that in the next 50 years your key will be compromised in some other way than factoring is sufficiently high to motivate this tactic. (In my view, it's vastly higher than that of your key being broken by factoring). Correct... and furthermore - this only dealt with transmitting the encrypted (and signed?) will, presumably to a trusted lawyer (or other trusted party). I would also be more concerned about the risk that the lawyer/party will be corrupted (by software or otherwise...) within the 50 years. Again the solution has nothing to do with ECC vs. RSA... This is a bit besides the original debate but let me quickly recall the three main techniques I know of protecting such a long-lasting secret data: -- Tamper-resistant hardware -- Splitting the data (or a strong symmetric key with which the data is encrypted) among several secure storage units (secret sharing) -- The same, but proactively re-hashing the shares periodically, so that an attacker must collect all shares during the same period (proactive secret sharing). Regards, Amir Herzberg See http://amir.beesites.co.il/book.html for lectures and draft-chapters from `secure communication and commerce using cryptography`; feedback welcome! - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Losing the Code War by Stephen Budiansky
Ben wrote: marius wrote: ... Not quite true. Encrypting each message twice would not increase the effective key size to 112 bits. There is an attack named meet in the middle which will make the effective key size to be just 63 bits. ?? 56 bits plus a little, surely. The `meet in the middle` attack works against double encryption; that's why Triple DES is performing three DES operations with two keys. There are some attacks also against using three encryptions with two keys and against Triple DES (encryption-decryption-encryption). But the attacks I know require huge amounts of chosen plaintext or known plaintext. In particular with t known plaintext-ciphertext pairs, the known attack on triple-DES requires 2^120-log(t) operations. I think most applications can limit the amount of known plaintexts to a million; this means the complexity of attacking triple-DES is at least 2^100, which is probably sufficiently secure for most applications. Of course, using three different keys for the three DES operations (in triple DES or simply in triple encryptions by DES) is expected to considerably improve security. I think the edge of AES is mostly when improved performance (esp. in software) is needed. Cheers, Amir Herzberg See http://amir.beesites.co.il/book.html for lectures and notes (draft of chapters) on `secure communication and commerce using cryptography`; feedback welcome! - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
available draft chapters and lectures on `secure communication and commerce using crypto`
Hi all, As you may already know, I'm working on a text-book, to be published by Prentice Hall, titled: Introduction to Secure Communication and Commerce Using Cryptography. Lectures covering much of the material, and a fair number of draft chapters, are now available online; see (link from) http://amir.beesites.co.il/book.html. I've recently added to the site few more lectures (payments, voting, trust,) and the chapter on micropayments. Still a long way to go, but I think it may already provide some value. You are encouraged to use the presentations and draft-chapters from that site (you'll find the chapters under `Notes` column). The material is copyrighted but you can use it for personal use and study, and definitely encouraged to use to give courses; please inform me of any non-personal use. My goal is to create a textbook which can be used for introductory courses in cryptography, secure communication and secure commerce payments (for undergrads and graduates). I appreciate your feedback and suggestions, in particular, please let me know if there are other areas you think I should cover. Enclosed is the current table of contents (most subject already contain lecture and/or draft/partial chapters others marked TBD): 1. Introduction 2. Security threats and requirements 3. Principles of Modern Cryptography 4. Cryptography I: encryption and randomness 5. Cryptography II: Hashing and Message Authentication (MAC) 6. Cryptography III: Public Key Cryptography 7. Cryptography IV: distributed and proactive cryptography (and secret sharing) [TBD] 8. PKI and certificates 9. Secure Communication I: network reliability and security (TCP/IP, firewalls, tunneling, denial of service) 10. Secure Communication II: Authentication, Authorization and Key Distribution 11. Secure Communication III: IP layer security (IPSec, IKE) 12. Secure Communication IV: transport layer security SSL, TLS, WTLS and WEP 13. Secure XML 14. Security, Trust and Reputation 15. Secure e-Banking and accounts [TBD] 16. Secure Payments I: overview, credit card payments, mobile payments 17. Secure Payments II: micropayments, money transfer 18. Privacy and anonymity: digital cash, anonymous communication [TBD] 19. Content Protection and Security for Remote Code 20. Trusted third party services Notary, e-vault, secure agents [TBD] 21. Advanced protocols voting, gambling, 22. Conclusion and social/legal issues [TBD] Cheers, Amir Herzberg
RE: Authenticating logos
Ron said, While valid claims (decision about trust is made based on logo, etc.), similar things happen outside of cyberspace. A person goes to ATT store, with a big logo in front, eventually gives his credit card information to the person sitting there. That person, maybe an employee of a dealer / franchise store owner (similar to the Palm case). Does that person trust the employee? probably not. Does he trust the store owner? Maybe not. He made his decision based on the logo in front, which may turn out to be fake. Absolutely correct; but, why can a person make this assumption? Because the legal system protects ATT's right to the logo, and ATT will invest heavily in going after anybody using their logo without authorization or improperly. A very important goal of secure commerce is to provide alternate mechanisms in cyberspace. This is since when a hacker is using ATT's logo in her website, it may not be feasible for ATT to sue him (in particular he may reside in places where logos are not protected as well...). Cryptography provides an alternative way to ensure `law and order`, by making reputation a tool for both prevention (you work only with reputable entities) and for reward and punishment (I'll give you a certificate if I'm happy with your work, and create a web site about your lousy service). Cheers, Amir Herzberg See http://amir.beesites.co.il for lectures and notes (draft of chapters) on `secure communication and commerce using cryptography`; feedback welcome! - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Authenticating logos
Eric said, I didn't say that it wasn't possible to secure logos. I said that you couldn't protect people who trusted logos that were transmitted to them in Web pages. This is not the same thing. The point is that such logos are transmitted in-band and are part of the web page. Therefore, they are not cryptographically verified. It is a pity that logos are not authenticated by SSL and displayed in a separate window. We've done an experimental implementation of a secure-logo, as a special frame in the browser, controlled by a (local or remote but in any case trusted) proxy. The proxy validates that the server has a certificate for the logo; standard SSL certificates may not provide this, but they can contain an address where the proxy can go get the necessary additional certificates. If anybody is interested in taking this project further, I'll be happy to help. Best, Amir Herzberg See http://amir.beesites.co.il for link to lectures and draft-chapters on `secure communication and commerce using cryptography`; feedback welcome! - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Forward Security Question
Seems that RFC 2828 only clarifies that not all people agree on a definition. Let me try to clarify, and since I'm just about to complete the lecture and chapter covering this area in my `secure communication and commerce` course (and book), I'll really appreciate comments/corrections. In particular I hope Robert Shirey (editor of rfc2828) is listening (I don't have his e-mail). First to the specific questions in the original note: ... Does the forward security refer to the fact that if Eve knows a K Alice and Bob used two weeks ago, she cannot assume either of their identities for a current transaction? No. The concepts covering this are `resilience to known-key attack` (when K is a session key derived from long-term `master` key(s)), and `proactive security` (when K denotes all secret keying info). Or does it mean that even if Eve knows the current K in use by Alice and Bob's session, she cannot impersonate either of them? I think I didn't understand this as this appears impossible trivially. Or does it mean something else? Bingo! :-) A reasonable definition for PFS appears in [MOV96], def. 12.16, p. 496 in my copy. Let me give here a slight variant (improvement I hope) to it: A protocol is said to have perfect forward secrecy if compromise of long-term keys at time t does not compromise PAST traffic, i.e. messages sent before t-T, even if attacker has all past (encrypted) traffic available. The value T is a constant (the length of key update period). Some related definitions/concepts: Known-key attack: this is an attack on a protocol which uses designated, multiple `session keys` to encrypt and/or authenticate messages, where all the `session keys` are exchanged using some other secrets (master, long-term keys) never used directly to encrypt or authenticate messages. The attacker is given the value of some session keys. A protocol is resilient to knonw key attack if an attacker with access to all traffic and to some session keys cannot decrypt messages encrypted with a key not given to him, and cannot authenticate messages using a key not given to him. Proactive security recovery: Consider the following scenario. Attacker compromises all keys of a party at time t (without the party being aware of it). A protocol provides proactive security recovery with period T if at t+T, either the attack is detected or security is restored (attacker cannot decrypt or forge future traffic). See formal definition and implementation in [CHH00]. Best regards, Amir Herzberg Please use my new e-mail: [EMAIL PROTECTED] [CHH00] Ran Canetti, Shai Ha-Levi and Amir Herzberg. Maintaining authenticated communication in the presence of break-ins. In Journal of Cryptography, Vol. 13, No. 1, January 2000, pp. 61-105. Extends version in Proceedings of the sixteenth annual ACM symposium on Principles Of Distributed Computing (PODC), 1997, Pages 15 - 24. [MOV96] Alfred J. Menezes, Paul C. van Oorschot, Scott A. Vanstone, Handbook of Applied Cryptography, CRC Press, ISBN 0-8493-8523-7, October 1996. Available online at http://www.cacr.math.uwaterloo.ca/hac/. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: crypto backdoors = terrorisms free reign
Hadmut replied to Jim: Incorrect. You will weaken the absolute security of many, but the few who choose to use strong (non-GAK) crypto will be easily distinguished from those who comply with the rules. No. It cannot be easily distinguished. That's the mistake almost all politicians do. Correct, but let me explain _why_. Suppose by law, everybody can use GAK encryption alg, say `GEEK`. Attacker wishes to use non-GAK algorithm, say `TRICK`. GEEK has a distinguisher module available to NSA which outputs GEEK or SUSPECT for encrypted data (using GEEK or any other algorithm, respectively). Attacker encrypts his data with TRICK and then with GEEK. So this is validly GEEK encrypted data. Until the NSA tries to decipher it, it looks fine. (As far as I know, sending this message is still legal. I definitely hope so.) Best, Amir Herzberg - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: The tragedy in NYC
Perry said, I do not want more laws passed in the name of defending my home. I do not want more freedoms eliminated to preserve freedom. I do not want to trade my freedom for safety. Franklin has said far more eloquently than me why that is worthless. If you must do something, send out more investigators to find those responsible for this and bring them to justice. Pass no new laws. Take away no freedoms. Do not destroy the reason I live here to give me safety. I'd rather die in a terrorist attack. I agree that there shouldn't be laws limiting crypto research and usage. But not since `I'd rather die than lose my freedom to use crypto`, which I think is a reasonable summary of Perry's argument. Most people will not agree; in fact, most people are willing to expose their privacy to receive low-value promotions or discount. They will not be willing to risk their lives for this. In fact, if giving up crytpto completely would help substantially to protect against terror, I'll support it myself. But... The real argument is simple: there is no evidence or convincing argument why shutting down crypto will substantially help defend against terrorism. It is a popular, easy solution, good for politicians as it is an easy `sell` to the public, but not effective. That's why we should defend against it; the negligible help it may provide to law-enforcement is not worth its cost in loss of privacy and commerce, in the loss of freedom, and in the dangers of abuse by government. Best, Amir Herzberg - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
e-journals in applied crypto / secure e-commerce
I'll appreciate recommendations of good, preferably referred, e-journals for reading and writing on applied cryptography and secure e-commerce. Thanks! Best regards, Amir Herzberg CTO, NewGenPay Inc. http://www.newgenpay.com/Amir/Herzberg.htm SMS (urgent only!): _subject_ of email to [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: No free spam
James E. Donald said, Amir Herzberg wrote: Another BTW, the other application I really want micropayments for (and was my first motivation to this if I recall correctly) is also crypto-related... it is to motivate people to produce reviews of products, services, and esp. other reviewers - creating a huge `web` (or directed graph) of credentials. If these are signed, and identify the reviewed entity by its public key, these credentials are certificates. Using such a collection of many credentials is what I believe will be the ultimate solution to public key infrastructure - and this is another area I'm very interested in (and worked on). On 15 May 2001, at 11:18, Ben Laurie wrote: I hear what you are saying, but I really don't see how this produces the ultimate solution to PKI - unless you envisage the huge web boiling down to a few very large players that I subcontract my ID requirements to. No, actually, the trust management decision becomes very decentralized. I interpreted Amir' Herzberg's plan as the Crypto Kong approach to credentials (www.echeque.com/Kong). If you have a bunch of readily accessible signed documents floating around on the web, you can determine the authenticity of any signed instrument by comparing the signature on one document to other signatures by that person, in those few cases where you actually are concerned about authenticity. The similarity seems to be only that both are not relying on identity certificates. But otherwise it's quite a different approach. In our system, we establish trust by building a graph from available certificates and other credentials of different entities in the network, and rules for assigning roles to secret-key holders based on their certificates/credentials and the role of the issuers of each. This raises a non-trivial, but feasible, computational problem, resulting in assigning roles to the requestor (as well as to all the issuers of certificates/credentials of the requestor). I'm not involved now in this effort but the project is still ongoing and you can even download and try out the system. Best regards, Amir Herzberg CTO, NewGenPay Inc. See demo and lectures/overviews/tutorials on crypto-security for mobile, e-commerce, etc. in http://www.newgenpay.com/mpay/course/course.html - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
