Deadline for Security in Distribute Computing - This Thursday!
Dear Colleagues, Due to the many requests for an extension, the program chair agreed to move the deadline for submission to PODC'03, and therefore also for the special track on Security in Distributed Computing. The new deadline is this THURSDAY, FEBRUARY 6. I think this could be a really great event due to the convenient location (Boston), key note lectures (By Lampson, Micali, Anderson, Lamport, Lynch, Meyer and Wright - at least the first three on security), two security tutorials, and the opportunity for interaction between the distributed computing, security and crypto communities. And I'm sure there will be interesting presentations and discussions. Even if you can't submit, you should plan to attend. As before, the Call For Papers can be found at http://www.podc.org/podc2003/security-track-cfp.html Instructions for how to submit electronically: http://www.podc.org/podc2003/cfp.html#how We look forward to your submissions! See you in Boston on July. Best regards, and apologies for cross-posting (as well as for sending this reminder too late...), Amir Herzberg Chair of the Security in Distributed Computing Track http://amir.herzberg.name - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
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 defe
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=3D134580416&zsection_id=3D268448455&slug=3Dcomdex21&date=3D>20021121 > ... - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
CFP: Security in Distributed Computing Special Track of PODC 2003
abstracts deviating significantly from these guidelines will be rejected without consideration of their merits. Late papers will not be read or considered. BEST STUDENT PAPER AWARD: A prize will be given to the best student paper. A paper is eligible if at least one author is a full-time student at the time of submission. This must be noted on the cover page. The program committee may decline to make the award or split it. Program Committee: Marcos Aguilera HP Labs Lorenzo Alvisi U. Texas Austin James AspnesYale U. Cynthia Dwork Microsoft Research Juan Garay Bell Labs Vassos Hadzilacos U. Toronto Amir Herzberg Bar-Ilan U. Markus JakobssonRSA Miroslaw Kutylowski Wroclaw U. & Signet Dahlia Malkhi Hebrew U. Boaz Patt-ShamirTel-Aviv U. Erez PetrankTechnion Rajmohan Rajaraman Northeastern U. Sergio Rajsbaum, Chair UNAM Antony Rowstron Microsoft Research Roberto Segala U. Verona Amin M. Vahdat Duke U. Conference Committee: Elizabeth Borowsky Boston Coll. General Chair Soma Chaudhuri Iowa State U. Treasurer Amir Herzberg Bar-Ilan U. Security-Track Chair Victor LuchangcoSun Labs Publicity Mark Moir Sun Labs Local Arrangements Gil Neiger Intel Labs Webmaster Sergio Rajsbaum UNAM Program Chair Steering Committee: Elizabeth Borowsky Boston Coll. Keith Marzullo U. Calif.-San Diego Yoram Moses Technion Gil Neiger, Chair Intel Labs Sergio Rajsbaum UNAM Aleta Ricciardi Valaran Corp. Nir Shavit Tel-Aviv U. & Sun Labs - 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
At 20:10 30/07/2002, James A. Donald wrote: > -- >On 30 Jul 2002 at 17:02, Amir Herzberg wrote: > > 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. > >Randomness is of course indefinable. A random oracle is however >definable. I'm not sure what you mean by `randomness` being undefinable, but yes, I'm familiar with the standard definitions of the random oracle assumption/method. And I already agreed (I think with David Wagner) that it seems that when analyzing under the random oracle methodology, a call to the random oracle extracts the randomness from the physical (imperfect) source of entropy (one of us actually need to spend few minutes to confirm this proof is indeed as simple as it seems). But that's not the question, I think. What we really want is some assumption which we can test SHA-1, or a new `hash` function (possibly with a public key) against, and which is sufficient to securely extract randomness. This assumption cannot be the `random oracle` since clearly SHA-1 (and any other given function) is _not_ a random oracle... ---- 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: 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]
X.509, SSL & security of decentalized certification (RE: RSA getting rid of trusted third parties?)
Ian Clelland said, > It makes sense, though, that a company should be able to issue > certificates for servers belonging to various departments within the > company. The organisation knows its own internals far better than RSA/Verisign/whoever ... ... > What root CAs are good at, and what they should be doing, is > authenticating the organisation itself. They can verify that the > organisation exists as described, and that the private key really is Agreed. But... > This shouldn't be a problem, as long as the signing certificate can > only be used to sign certificates within that organisation. ... >... I don't know enough about the format of X.509 certs to say for sure >that this is true. This is not as simple as one may expect. X.509 has a hierarchy mechanism designed for allowing organizations issue (or at least control) certificates of departments and employees - the Distinguished Name (DN) and its keywords. However, browsers normally identify the server by its DNS name, which is usually included in the dNSName attribute in the subjectAltName extension, rather than in the X.509 DN. DNS names do not have a completely well defined structure, which makes it difficult to limit the organization's CA to issuing certs only to its employees and departments (e.g. would IBM's CA be able to issue certs for www.ibm.co.uk ?). Anyway, the validation is up to the browser - it is _not_ part of the SSL/TLS functionality. Furthermore, while X.509 and PKIX have mechanisms to allow a root CA to restrict the scope of certificates issued by a root CA, these mechanisms seem to focus on restricting the distinguished names in the issued certificates, rather than the subjectAltName (and in particular the DNS name). So my bet is that all or most browsers will not reject certificates with arbitrary DNS names issues by a corporation with a CA certified by RSA (or any other root CA). The problem here is not with the decentralized certification, IMHO; the problem is with the overly simplistic view of trust. The relying parties (e.g. browsers) should have tools that map each issuer of certificates to a `role` defining what it is trusted for. There have been lots of research in this direction (including a bit of my own) but it was not yet deployed in mainstream products such as browsers and web servers. BTW, I find Eric Rescola's book `SSL and TLS` coverage of the use of X.509 in SSL/TLS and browsers very informative and readable. I also cover this in my PKI and SSL lectures from the site below (but I have only a very early PKI chapter in the site and haven't begun on the SSL chapter, so for text please see Eric's book). Regards, Amir Herzberg See http://amir.herzberg.name/book.html for lectures and draft-chapters from book-in-progress, `secure communication and commerce using cryptography`; feedback 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 AT&T 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 AT&T's right to the logo, and AT&T 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 AT&T's logo in her website, it may not be feasible for AT&T 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]
FW: U.S. Police and Intelligence Hit by ISRAELI Spy Network ???????????
Ron Rivest said: >I found the following four-part report by Carl Cameron rather shocking: > >Part 1: http://www.foxnews.com/story/0,2933,40684,00.html [skipped - these links appear not to work any more] > >Why should we be freely giving to Israeli corporations >information (call records, CALEA information) that requires ...(skiped) >A more recent story indicates that the compromise was >probably severe; criminals were escaping detection >because of the compromise: > http://www.newsmax.com/archives/articles/2001/12/18/224826.shtml Well, this link does work, and the story there is incredible, and if true, really terrible - esp. for Israel. I hope this is not correct. I am looking for more information. In fact, initially I even thought maybe it wasn't Ron but a pure hoax but he confirmed he sent the note and saw this in Fox also... SO: anybody able to shed more light on this amazing story, please do!! (I hope - showing it's nonsense...) Cheers, Amir Herzberg p.s. I'm leaving here this week, back to academia, research and consulting - so reply to [EMAIL PROTECTED] or on the list as appropriate. - 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: Which internet services were used? (Home of the Brave)
Perry replied to Eric: > > The claim is that automobiles or telephones do not evicerate the ability of > > law enforcement to effectively do their job, while the use of strong > > encryption and other electronic sundry do. Therefore, it is argued that > > cars and certain phones are ok, while strong encryption is not. > > This claim is, however, wrong. > > First, lets look at the question of automobiles. Automobiles certainly I think Perry makes a good case for Automobiles. But why ignore the airplanes? This crime would be impossible if there were no civilian airplanes allowed. If necessary, the airforce could provide flight services. Of course, passangers must be chained, as standard precaution; this is only a minor inconvinience, well worth the improved security, as the crew will only be to happy to help passangers relieve themselves, with reasonable if not perfect privacy. Another advantage of preventing air traffic (and preferably also cars, as Perry already argued), would be to make contact between terrorists via face to face meeting more difficult. By forcing people to communicate electronically, and without (legal) encryption, we can substantially reduce the percentage of successful attacks (there are some critics who may claim it may increase the number of terrorists, but we can always ignore these). One last suggestion: the special aircrafts as well as the chains will be decorated with American heritage, to show America will not give in so easily, e.g. `Welcome to America, Home of the Brave`. I must however disagree with Perry's ending comments: > There is also the question of skill. Even if you could find every copy > of PGP on earth and erase it, if Ossama bin Laden could get his people > trained as pilots, what would be so hard about getting them copies of > Bruce Schneier's book? Or do you plan to ban it and all the others? What do you mean `ban it`? Definitely, US forces should _eliminate_ all these dangerous weapons, by searching libraries worldwide. We expect every freedom-loving nation to help, but it may be that we'll need to use force with some countries. There is always the danger of some copies made, but that's pretty easy to prevent; copy and press machines have been abused by terrorists for centuries and it is high time to control their use. We still have the technology to do so; let's use it now, then we can get rid of these dangerous computer science departments. 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]
RE: Field slide attacks and how to avoid them.
John says, > I've been noticing a lot of ways you can mess up a cryptographic > protocol due to the "sliding around" of fields within a > signed or MACed > message. The classic example of this is the old attack on PGP > fingerprints, which let you use some odd keysize, and thus get two > different keys (with different keysizes) with the same hash, without > breaking the hash function. (The raw bits of the two keys > are the same, > but the fields are broken up differently.) Use MAC function properly designed to prevent such attacks, such as HMAC http://www.ietf.org/rfc/rfc2104.txt. Best, Amir Herzberg - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
RE: GESG Identity-Based Public Key Cryptography (ID-PKC)
ID based public key is not a new concept, I believe first proposed by Adi Shamir in Crypto 84 (the first I attended :-). It's a cute concept, but I'm skeptic about its practical value - except of course as a way to force parties to use private keys known to authorities :-( The security requirement of ID based PKC is challanging, even more than `regular` PKC (which is obviously a special case). So there were many works proposing systems and also many attacks - although recently there are some proposals with proofs of security (with strong assumptions...), e.g. Boneh & Franklin in upcoming Crypto, see http://crypto.stanford.edu/~dabo/abstracts/ibe.html. But, what is the practical value of ID based systems? Not sending the public key? Give me a break... > M Taylor wrote: > > The UK Communications-Electronics Security Group (CESG), the "defensive" > > arm of the GCHQ, have published details about another PKC concept, > > identity-based PKC, where every user's public key are predetermined by an > > unique identifier, such as email address. It does use a(/two) trusted > > server(s), but might be viewed as an easier to use infrastructure than > > tranditional PKI in some situations. In what scenarios exactly? Many PKI scenarios are not ID specific at all - ID is just one way to establish trust... And even when people use IDs, why assume everybody trusts (completely!) the same authority? Best, Amir - 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 A. Donald said, > Amir Herzberg: > > 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 do not find this explanation intelligible. There had > better be a more intelligible explanation available > somewhere, because if the users do not understand it, they > will not use it. I apologize for the e-mail description being not clear enough. May I recommend that if you are interested, please read some of the papers we published on this, available from my site (below) or following `trust establishment` from www.hrl.il.ibm.com. 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]
No free spam
Ben responded to me thus: > > This takes care reasonably well of peer to peer e-mail (I think), and can be > > easily deployed (any volunteers? I'll be very glad to provide our system for > > this !). > > Sure. Is it something I can actually deploy (without everyone else in > the world also deploying it)? You can certainly deploy our system, as well as several others, e.g. one response mentioned correctly MojoNation (of course there are plenty of reasons to choose ours :-). I was puzzled by your saying `without everyone else in the world also deploying it`. I thought you meant that you are concerned that others will use it, making your deployment redundant or not commercial etc. Now when writing this to you I realize I stupidly misunderstood you. What you meant, I'm quite sure now, if that you are concerned that if you implement such a payment solutions others will not be able to mail you since they don't have it. Now that's a very valid concern and I also thought for a long time it may be a show stopper. But now I actually think it could work. Let me explain how. The key is the belief that micropayment systems MUST emerge - and be interoperable. That is a payer with account at one Payment Service Provider (PSP) should be able to pay anybody with account at any PSP. That's certainly our goal - our system has this property and we plan to work closely with any other vendor which will want to have this property to ensure interoperability. Assuming this, the problem is only the bootstapping phase, before everybody has accounts in interoperable PSPs. But in that phase when the system is not yet so widely used, it will be sufficient to force the sender to simply do some manual process - such as enter a web site to open a demo account and pay. That's clearly something achievable with our system or others. If it becomes popular, spammers may develop automated tools to do so as well, but that will buy them very little as at that point the system will be popular enough to move to real payments. BTW, I've been thinking of payments as the answer to spamming already for many years, and in fact it was one of my motivations for working on micropayments (from which our broader payment platform emerged). There are others who thought of it long ago, in particular Kevin Mccurly (see http://www.almaden.ibm.com/cs/k53/pmail/tsld001.htm). 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). 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 > -Original Message- > From: Ben Laurie [mailto:[EMAIL PROTECTED]] > Sent: Monday, May 14, 2001 9:08 PM > To: Amir Herzberg > Cc: 'Eugene Leitl'; Russell Nelson; [EMAIL PROTECTED] > Subject: Re: forwarded message from [EMAIL PROTECTED] > > > Amir Herzberg wrote: > > This takes care reasonably well of peer to peer e-mail (I > think), and can be > > easily deployed (any volunteers? I'll be very glad to > provide our system for > > this !). > > Sure. Is it something I can actually deploy (without everyone else in > the world also deploying it)? > > Cheers, > > Ben. > > -- > http://www.apache-ssl.org/ben.html > > "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] > - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
RE: forwarded message from tylera19@hotmail.com
Peter said, > Does the recipient get paid? The recipients of spam/ads? I've > got unlimited email addresses ... That's good! Nobody forces people to send junk (e)mail. It should cost them something. Some people may contribute this automatically to charity, others may keep it, others yet may use a mail service provider who will keep it (or part of it). People who send unsolicited (e)mail should pay for it - so they think twice before sending to all of your e-mail addresses! 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]
RE: forwarded message from tylera19@hotmail.com
Eugene said, > However, filtering is clearly the wrong solution. Whether > they realize it or not, spammers apparently press forward towards the end of > free email. A classical tragedy of the commons scenario: they'll ruin the > fun for us and themselves as well. It is not necessarily the end of free e-mail; a bearable restriction is sufficient. Specifically, e-mail readers and servers will be configured to send a polite refusal to any non-paid e-mail from an unknown source. This means that your _first_ e-mail to people using such a filter-by-charging solution will require a small payment. Assuming they consider you a non-spammer, they should return the payment to you (or simply not deposit it). This takes care reasonably well of peer to peer e-mail (I think), and can be easily deployed (any volunteers? I'll be very glad to provide our system for this !). As to mailing lists like this one... Here one solution is manual moderating, of course. But for a fully automated list... maybe a charge per posting which is proportional to the number of subscribers (well, like an ad, I guess). 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 > -Original Message- > From: Eugene Leitl [mailto:[EMAIL PROTECTED]] > Sent: Monday, May 14, 2001 6:42 PM > To: Russell Nelson > Cc: [EMAIL PROTECTED] > Subject: RE: forwarded message from [EMAIL PROTECTED] > > > On Mon, 14 May 2001, Russell Nelson wrote: > > > Somehow the term "cover traffic" comes to mind at this point. :-) > > This is off-topic, but unless the message is entirely uniquely worded, > requiring semantic parsing (and some not so primitive AI to be able to > generate it), it still shows up on the radar screen by virtue > of it being > spam (i.e. using advanced pattern matchers from > bioinformatics on message > body instead of a simple cryptohash, ranking every email message vs. > every email message passing through a given ISP). > > However, filtering is clearly the wrong solution. Whether > they realize it > or not, spammers apparently press forward towards the end of > free email. A > classical tragedy of the commons scenario: they'll ruin the > fun for us and > themselves as well. > > > > > - > The Cryptography Mailing List > Unsubscribe by sending "unsubscribe cryptography" to > [EMAIL PROTECTED] > - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
move to NewGenPay; and, collecting secure e-commerce resources
Hi all, First, I've recently left IBM as part of the spin-off of our payments project into NewGenPay. My IBM e-mail was supposed to forward but I think they've recently cancelled it, so please use my new email. Secondly, I plan to extend further the collection of secure e-commerce resources I've begun in IBM. I've already put in the demo area of our site (www.NewGenPay.com) the old stuff - my lectures and overviews of different areas of secure e-commerce, secure payments, and applied cryptography. It includes a few links but I'll like to expand that much more to make it a useful community resource. While almost all that we currently have is `sold` with our `demo money`, the new parts will mostly be regular links, of course I'll leave a bit of our `per-fee links` so people have motivation to use our demo... (but we had thousands of people doing it Ok - it's very easy). I'll appreciate, therefore, suggestions of useful technical and educational resources that I should include there. Examples are lectures and courses available online, archives, standards, forums, etc. I won't try to cover purely commercial sites or in general any non-technical/educational sites. BTW, if some of you have relevant lectures/tutorials/overviews in relevant areas that you prefer we'll put in out site (e.g. it is difficult for you to host them), I'll be happy to host a reasonable number of well written resources. Best regards, Amir Herzberg CTO, NewGenPay Inc. See our demo and overview/tutorials on secure e-commerce in http://www.NewGenPay.com - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
