Re: Java: Helping the world build bigger idiots
It used to be that checking bounds on certain collections was less
efficient than waiting for the out of bounds exception. I think Joshua
Bloch discusses this in his book.
I've also seen this in generated code where you aren't sure of the
nature of the object you're indexing and thus don't know the
appropriate length variable (.length vs .length()).
That said it's still awful.
On 9/19/05, Peter Gutmann [EMAIL PROTECTED] wrote:
Found on the Daily WTF, http://www.thedailywtf.com/forums/43223/ShowPost.aspx:
try {
int idx = 0;
while (true) {
displayProductInfo(prodnums[idx]);
idx++;
}
}
catch (IndexOutOfBoundException ex) {
// nil
}
The editor also comments that when he got the first few of these submitted he
rejected them as being faked, but ended up with so many that he realised this
usage must be relatively common.
Peter.
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
--
Jeremiah Rogers
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RFID Payments
I've got Dave's updated article here, for them as wants it... http://www.philodox.com/pdfs/RFID_Payment_Security_2.pdf Cheers, RAH --- begin forwarded text Subject: RFID Payments Date: Mon, 19 Sep 2005 17:21:14 +0100 From: Dave Birch [EMAIL PROTECTED] To: [EMAIL PROTECTED], Bob Hettinga [EMAIL PROTECTED], Ian Grigg [EMAIL PROTECTED] John (and Bob and Ian), Thanks for the interest in the article, which I really appreciate. I can safely say I had no idea that NCC IT Advisor was so widely read! http://www.nccmembership.co.uk/pooled/articles/BF_WEBART/view.asp?Q=BF_WEBART171100 Interesting article, Thanks, much appreciated. but despite the title, there seems to be no mention of any of the actual security (or privacy) challenges involved in deploying massive RFID payment systems. Please find enclosed an updated draft of a longer version, which I hope helps to stimulate this debate further. E.g. I can extract money from your RFID payment tag whenever you walk past, whether you authorized the transaction or not. You can extract a transaction, certainly. But not money: the only place the money can go to is a merchant acquiring account (if you're talking about Visa, MC, Amex schemes). And even assuming you wanted it this way, if your Nokia phone has an RFID chip in it, who's going to twist the arms of all the transit systems and banks and ATM networks and vending machines and parking meters and supermarkets and libraries? Transit is a special case, so let's put that to one side for a second. As for banks, supermarkets etc: they're already installing the terminals. Their first reaction is going to be to issue you an RFID themselves, and make you juggle them all, Just like your existing payment cards. rather than agreeing that your existing Nokia RFID will work with their system. No, not really. Your Nokia phone will become your Visa or MC card and therefore work with the terminals. Things may develop in a different direction in the world of NFC, but that's a different issue (ie, phone as POS terminal rather than phone as card). If you lose your cellphone, you can report it gone (to fifty different systems), and somehow show them your new Motorola RFID, but how is each of them going to know it's you, rather than a fraudster doing denial of service or identity theft on you? Very good point, and this will have to be addressed. Then there's the usual tracking people via the RFIDs they carry problem, which was not just ignored -- they claimed the opposite: Remote tracking is a non-issue with these schemes, the range is too short. I'll track the tag on your shirt rather than your card. This kind of solution provides privacy, because the token ID is meaningless to anyone other than the issuing bank which can map that ID to an actual account or card number. That is only true once -- til anyone who wants to correlates that token ID blob with your photo on the security camera, Or the loyalty card I used in the transaction. But your point is correct: using my MasterCard keyfob gives me privacy from the clerk etc, but of course it is not designed to be impervious to correlated data fusion. your license plate number (and the RFIDs in each of your Michelin tires), the other RFIDs you're carrying, your mobile phone number, the driver's license they asked you to show, the shipping address of the thing you just bought, and the big database on the Internet where Equifax will turn a token ID into an SSN (or vice verse) for 3c in bulk. That's a different kind of privacy. I am not claiming that the payment tokens being introduced provide any kind of anonymity. Nor do they and nor, as far as I am aware, will it ever be one of their design goals. The article seems to have a not-so-subtle flavor of boosterspice. Absolutely. I love contactless payments. Anybody got a REAL article on contactless payments and security challenges? Please let me have a copy as I'm interested in anything around this topic. And thanks again for taking the trouble to comment: I genuinely do value the input. Best regards, Dave Birch. -- -- David Birch, Director, Consult Hyperion www.chyp.com -- -- Tweed House, 12 The Mount, Guildford GU2 4HN, UK -- voice +44 (0)1483 468672, fax +44 (0)8701 338610 -- -- Digital Identity 6, 25th/26th October 2005 www.digitalidforum.com --- end forwarded text -- - R. A. Hettinga mailto: [EMAIL PROTECTED] The Internet Bearer Underwriting Corporation http://www.ibuc.com/ 44 Farquhar Street, Boston, MA 02131 USA ... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience. -- Edward Gibbon, 'Decline and Fall of the Roman Empire' - The Cryptography Mailing List
Guideline for Implementing Cryptography In the Federal Government
http://csrc.nist.gov/publications/drafts/800-21-Rev1_September2005.pdf --Steven M. Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
[Clips] [MTNews] CRYPTOCard DEMONSTRATES CRYPTO-Server 6.3
--- begin forwarded text Delivered-To: [EMAIL PROTECTED] Date: Mon, 19 Sep 2005 15:04:54 -0400 To: Philodox Clips List [EMAIL PROTECTED] From: R.A. Hettinga [EMAIL PROTECTED] Subject: [Clips] [MTNews] CRYPTOCard DEMONSTRATES CRYPTO-Server 6.3 Reply-To: [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] --- begin forwarded text Date: Mon, 19 Sep 2005 09:59:24 -0700 To: [EMAIL PROTECTED] From: MacTech News Moderator [EMAIL PROTECTED] Subject: [MTNews] CRYPTOCard DEMONSTRATES CRYPTO-Server 6.3 Sender: [EMAIL PROTECTED] This message comes to you from MacTech News -- the Mac(tm) OS Technical News and Info server. See below for more info on this list (including sub/unsub details). __ CRYPTOCard DEMONSTRATES CRYPTO-Server 6.3 FOR OS X AT APPLE EXPO IN PARIS: CRYPTO-Server 6.3 SETS NEW STANDARD IN FULLY-INTEGRATED TWO-FACTOR AUTHENTICATION FOR PANTHER AND TIGER USERS PROVIDES ATM-STYLE ACCESS TO DESKTOPS, LAPTOPS, AND APACHE WEB SERVERS Fully Compatible With Tiger's Support For Smart Cards, CRYPTO-Server 6.3 For OS X Provides Simple Authenticated Access To Desktops-Even If The User Is Not Connected To The Network! PARIS, FRANCE, September 19, 2005 CRYPTOCard (http://www.cryptocard.com/), a leading authentication developer, will demonstrate CRYPTO-Server 6.3 for OS X, the authentication solution designed to make it simple to positively identify all Panther and Tiger users attempting LAN, VPN (Apple or Cisco), or Web-based (Apache) access, at the Apple Expo (booth 22) in Paris from September 20th through 24th. Specifically designed to fully integrate with Tiger's robust support for smart card environments, CRYPTO-Server 6.3 couples something in the user's possession (a multi-function smart card, USB token, hardware token, or software token), with something the user knows (their PIN) to provide secure, enterprise-class LAN, Web, and remote ATM-style One-PIN-and-Youre-In authenticated access that mirrors the look and feel of the OS X logon ensuring that the technology is simple for Tiger and Panther users to utilize. CRYPTO-Server 6.3's Fast User Switching functionality also makes it simple for multiple Tiger users to securely access the Mac, using smart cards or tokens in a stand-alone or networked environment. Incorporating CRYPTOCard's familiar ATM-style logon, that has proven to eliminate the user resistance usually encountered when organizations attempt to implement an additional layer of security, CRYPTO-Server 6.3 for OS X generates a one-time password for every log-on attempt, making stolen credentials useless to hackers while simultaneously ensuring Tiger and Panther users do not have to memorize complicated credentials significantly reducing the help-desk costs associated with resetting forgotten passwords, and the obvious security risk resulting from users writing down their passwords. Understanding that an organization cannot guarantee a system security if it cannot positively authenticate each individual user, CRYPTOCard has developed a fully-integrated authentication solution specifically designed for Tiger and Panther, commented Malcolm MacTaggart, President CEO, CRYPTOCard Corporation. CRYPTO-Server 6.3 now makes it simple for Tiger and Panther users, particularly in the traditional Mac strongholds of the health, legal, higher education, and printing/publishing/multimedia sectors, to provide true ATM-style One-PIN-and-Youre-In enterprise-class strong user authentication for LAN, VPN, Web, or remote system access. CRYPTOCard's CRYPTO-Logon feature makes it easy for OS X users attempting to gain secure LAN, Web, or remote access to the system to authenticate themselves to the CRYPTO-Server by simply inserting their smart card and entering their PIN. To log off, the user simply removes their smart card to lock the desktop. CRYPTO-Server 6.3 for OS X's Fast User Switching functionality makes it simple for multiple users to utilize CRYPTOCard's familiar ATM-style protocol to gain authenticated access via the same computer in stand-alone and, or, in network environments. CRYPTO-Server's remote access functionality offers support for Apple's VPN Server, with the same One-PIN-and-Youre-In. experience, however, if hardware tokens are employed, no additional software is required on the client side CRYPTOCard's two-factor-authentication is ready to go, out-of-the-box. CRYPTO-Server 6.3's CRYPTO-Web component also makes it simple for Tiger users to utilize the exact same ATM-style log-on protocol to positively authenticate themselves to Apache and IIS Websites, right down to the page level. And, with almost 75 percent (or more than 13 million) of the world's web servers running on Apache, CRYPTO-Server 6.3 for OS X represents a significant advance in authentication technology for the web medium. Building on CRYPTOCard's
Defending users of unprotected login pages with TrustBar 0.4.9.93
Amir Herzberg writes: However, quite a few of these sites invoke SSL/TLS only _after_ user has typed in her user name and pw, and clicked `submit`. This allows a MITM adversary to send a modified login page to the user, which sends the pw to the attacker (rather than encrypting it and sending to the site). See below link to a `Hall of Shame (HoS)` listing such sites. There are few things we can do about this. We can try to convince these sites to use SSL/TLS _before_ asking for userid and pw; I tried, and few fixed, but most did not. But this isn't enough. The only way for a user to be secure against such attacks is to type in a https:-style URL into the address bar directly, or to load a https:-style URL from a bookmark. Users have to always remember to type in https://www.bank.com; they must never use http://www.bank.com, or they will be insecure. Training users to follow this discipline is not a trivial task. I'm not sure it is fair to blame this solely on the web sites. The problem is that the https: model for web security is broken, if attackers are mounting active attacks, DNS spoofing, and other kinds of man-in-the-middle attacks. The problem is not with SSL; the problem is with the model for how SSL is applied to solve the web security problem, and with the user interaction model. Fixing this probably requires changes to web browsers and/or web servers. So, a Hall of Shame seems a little over the top to me, since there is no obvious way that the web site could fix this on its own. TrustBar's solution to this conundrum is a nice one. I like it. But it does require changing the web browser. One thing that web sites could do to help is to always make https://www.foo.com work just as well as http://www.foo.com, and then browser plug-ins could simply translate http://www.foo.com - https://www.foo.com for all sensitive sites. Of course, web site operators may be reluctant to take this step on performance grounds. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Defending users of unprotected login pages with TrustBar 0.4.9.93
Perhaps the idea of automatically redirecting people to alternative pages goes a bit too far: 1. TrustBar will automatically download from our own server, periodically, a list of all of the unprotected login sites, including any alternate protected login pages we are aware of. By default, whenever a user accesses one of these unprotected pages, she will be automatically redirected to the alternate, protected login page. How convenient! So if I could hack your server, I could get all TrustBar users' accesses -- to any predefined set of pages on the Internet -- to be redirected to scam pages. A redirect to an untrustworthy page is just as easy as a redirect to a trustworthy page. The question is who you trust. BTW, TrustBar is an open-source project, so if some of you want to provide it to your customers, possibly customized (branded) etc., there is no licensing required. Also providing a handy platform for slightly modified versions, that will take their cues from a less trustworthy list of redirects. John - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Java: Helping the world build bigger idiots
On 9/19/05, [EMAIL PROTECTED] (Peter Gutmann) wrote:
Found on the Daily WTF, http://www.thedailywtf.com/forums/43223/ShowPost.aspx:
try {
int idx = 0;
while (true) {
displayProductInfo(prodnums[idx]);
idx++;
}
}
catch (IndexOutOfBoundException ex) {
// nil
}
This is obviously just an attempt to make Java array access more like Java file
access. :-)
Seriously, the real flaw in this approach, which I did not see mentioned in the
comments on the web page Peter references above, is the masking of
IndexOutOfBoundExceptions that may be generated by displayProductInfo. This
code will treat such errors as end of array. A more normal coding of the
loop:
for (int i=1; iprodnums.length; i++) {
displayProductInfo(prodnums[idx]);
idx++;
}
would let the exception pass up the call chain, and with good error handling,
the problem would come to the attention of those responsible for fixing the
program.
If ArrayIndexOutOfBoundException were used instead of IndexOutOfBoundException,
errors in string indexing would pass up the call chain, while catching array
problems.
Cheers - Bill
-
Bill Frantz| The first thing you need | Periwinkle
(408)356-8506 | when using a perimeter | 16345 Englewood Ave
www.pwpconsult.com | defense is a perimeter.| Los Gatos, CA 95032
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Online fraud 'ahead' of credit-card companies-experts
http://news.yahoo.com/s/nm/20050919/wr_nm/financial_creditcard_fraud_dc;_ylt=AlItQtA0cAs1.5FbhmH_orX6VbIF;_ylu=X3oDMTBiMW04NW9mBHNlYwMlJVRPUCUl Online fraud 'ahead' of credit-card companies-experts Speaking at an conference here, John Shaughnessy, senior vice president for fraud prevention at Visa USA and Suzanne Lynch, vice president for security and risk services at MasterCard International, said that organized crime rings .. snip ... The picture they presented of an escalating struggle between commerce and criminality offered little hope of quick relief for consumers worried about identity theft or for investors in card-issuing banks concerned about security's escalating costs. ... snip ... - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
[EMAIL PROTECTED]: [IP] more on ARMSTRONG LECTURE on Quantum Crypto and Optical Networks (Forwarded)]]
- Forwarded message from David Farber [EMAIL PROTECTED] - From: David Farber [EMAIL PROTECTED] Date: Mon, 19 Sep 2005 20:30:36 -0400 To: Ip Ip ip@v2.listbox.com Subject: [IP] more on ARMSTRONG LECTURE on Quantum Crypto and Optical Networks (Forwarded)] X-Mailer: Apple Mail (2.734) Reply-To: [EMAIL PROTECTED] Begin forwarded message: From: Rod Van Meter [EMAIL PROTECTED] Date: September 19, 2005 7:25:19 PM EDT To: Joe Touch [EMAIL PROTECTED], [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], David Wagner [EMAIL PROTECTED] Subject: Re: [Fwd: Re: [IP] ARMSTRONG LECTURE on Quantum Crypto and Optical Networks (Forwarded)] Reply-To: [EMAIL PROTECTED] [Dave, for IP, if you wish...] I generally agree with Dave Wagner's response, but a few thoughts... The physicists are indeed working on quantum repeaters, capable of doing QKD over long distances. The trouble is, you have to trust every one of the repeaters. I wouldn't phrase the fiber security issue quite the same way. As others have said, what you need is access to an authenticated channel, then you're set (but that's a non-trivial problem!). It's important to note that a) QKD does NOT solve what Shor's factoring algorithm broke, and b) key exchange/distribution is not the biggest security problem we have on the net (it might not even make the top ten). The one possibly interesting use of QKD is for the super-paranoid: those who believe their traffic is being snooped today, and don't want it decrypted fifty years from now when theoretical and technological advances render all classical cryptography breakable (!?!). But in order for that to work, you have to use the QKD-generated random bit string as a one-time pad, not just a seed or key for classical encryption. That means you need very high QKD bit-generation rates, and most are still in the kilobits/second. Some experiments have been done in the low megabits/sec., but that's pre-filtering, I believe, which costs you at least one order of magnitude in performance. If you do it right, then, authentication that is good enough TODAY, plus QKD to generate a random one-time pad, can make your data secure FOREVER (modulo breakins/breakdowns at the endpoints). Even if your authentication is broken later, since it's not used in the actual data exchange, the attacker gains no data. This is covered in Paterson et al.'s paper. I arrived at the party a little late to get in on the recent thread at Dave Bacon's Quantum Pontiff blog, but I did throw in my two cents anyway: http://dabacon.org/pontiff/?p=1049#comments Dave's blog is an excellent source for current news and gossip, and is read (and commented on) by many of the best names in the biz. btw, Steve, not sure if you're aware of it or not, but Al Aho's student Krysta Svore is doing quantum stuff for her thesis. She just spent a year in Cambridge working with Ike Chuang, but is back at Columbia, I understand. She's pretty sharp. --Rod - You are subscribed as [EMAIL PROTECTED] To manage your subscription, go to http://v2.listbox.com/member/?listname=ip Archives at: http://www.interesting-people.org/archives/interesting-people/ - End forwarded message - -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07100, 11.36820http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
Re: Defending users of unprotected login pages with TrustBar 0.4.9.93
John Gilmore wrote: Perhaps the idea of automatically redirecting people to alternative pages goes a bit too far: Of course, users can turn this off for one page or for all, but that's not answering yet John's comments below - I respond following them... Also: I am not crazy about this solution either, but I think the current situation, where very large banks insist on providing unprotected login pages, is even worse. I tried convincing them, and I must say few did change, e.g. Wells Fargo I think. I'll be happy to hear of better solutions (or do you think the current state is better?). 1. TrustBar will automatically download from our own server, periodically, a list of all of the unprotected login sites, including any alternate protected login pages we are aware of. By default, whenever a user accesses one of these unprotected pages, she will be automatically redirected to the alternate, protected login page. How convenient! So if I could hack your server, I could get all TrustBar users' accesses -- to any predefined set of pages on the Internet -- to be redirected to scam pages. What if the list is signed by one or more authorities that users are willing to trust to this matter? Or just have the list in a trusted site - after all, if someone breaks Google, they can redirect much more than by attacking our server... A redirect to an untrustworthy page is just as easy as a redirect to a trustworthy page. The question is who you trust. We are not redirecting to a trustworthy site (e.g., your bank is insecure, try that one instead...). We simply redirect to an SSL protected page of the same entity (bank) if we know one. BTW, TrustBar is an open-source project, so if some of you want to provide it to your customers, possibly customized (branded) etc., there is no licensing required. Also providing a handy platform for slightly modified versions, that will take their cues from a less trustworthy list of redirects. Are you now against open source in general? After all, for this attack, Mozilla would be a much better target... In fact, since `everybody` uses Windows, any stupid program can redirect users to fake sites - and do much worse... Anyway - thanks for the feedback. -- Best regards, Amir Herzberg Associate Professor Department of Computer Science Bar Ilan University http://AmirHerzberg.com Try TrustBar - improved browser security UI: http://AmirHerzberg.com/TrustBar Visit my Hall Of Shame of Unprotected Login pages: http://AmirHerzberg.com/shame - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Defending users of unprotected login pages with TrustBar 0.4.9.93
David Wagner wrote: Amir Herzberg writes: However, quite a few of these sites invoke SSL/TLS only _after_ user has typed in her user name and pw, and clicked `submit`. This allows a MITM adversary to send a modified login page to the user, which sends the pw to the attacker (rather than encrypting it and sending to the site). See below link to a `Hall of Shame (HoS)` listing such sites. There are few things we can do about this. We can try to convince these sites to use SSL/TLS _before_ asking for userid and pw; I tried, and few fixed, but most did not. But this isn't enough. The only way for a user to be secure against such attacks is to type in a https:-style URL into the address bar directly, or to load a https:-style URL from a bookmark. Why? What's your threat model? From the follow on, it seems you are concerned that even if the site's homepage say http://chase.com would redirect to https://chase.com, like etrade for instance do, this can be redirected by a MITM attacker. Similarly, if the homepage only contains a link to the https: protected login page, like most banks do e.g. Citibank, then again a MITM may redirect this to his own page. The user may not notice this change in address. In fact, with current browser UI, we know - by common sense and experiments - that almost all users will fail to notice such attacks. But our early experimental data with TrustBar seem to show that with improved UI, most users may be able to detect such spoofing attempts. Moreover, a MITM attack may be done even if the user types https://... A MITM may reply to the SSL connection itself (e.g. via DNS spoofing). True, the browser expects a certificate for say chase.com and now will get a cert for a different site, so the user gets a warning message; however, this is the sort of messages that users often click-away without reading and definitely without understanding. Furthermore, the attacker may even get a cert for the original address from one of the less-trustworthy CAs supported by the browser, in which case there is not even a warning - with current browser UI. TrustBar provides indicators which seem to allow most or at least many naive users detect such attacks (involving a non-trustworthy CA). Users have to always remember to type in https://www.bank.com; they must never use http://www.bank.com, or they will be insecure. Training users to follow this discipline is not a trivial task. Impossible task, imho. I'm not sure it is fair to blame this solely on the web sites changes to web browsers and/or web servers. So, a Hall of Shame seems a little over the top to me, since there is no obvious way that the web site could fix this on its own. Web sites should use SSL to protect their login forms (and redirect from http if user tries to use it). This does leave the possibility of users being redirected to other sites, but at least the site has done the best it can. Indeed, very few non-US banks expose their customers in this way. TrustBar's solution to this conundrum is a nice one. I like it. But it does require changing the web browser. Thanks, and yes, I agree, this requires browser change, I don't think we can avoid this. Users can currently use our extension, and we hope that as more and more do so, browers makers will add such features. One thing that web sites could do to help is to always make https://www.foo.com work just as well as http://www.foo.com, and then browser plug-ins could simply translate http://www.foo.com - https://www.foo.com for all sensitive sites. Of course, web site operators may be reluctant to take this step on performance grounds. Correct. -- Best regards, Amir Herzberg Associate Professor Department of Computer Science Bar Ilan University http://AmirHerzberg.com Try TrustBar - improved browser security UI: http://AmirHerzberg.com/TrustBar Visit my Hall Of Shame of Unprotected Login pages: http://AmirHerzberg.com/shame - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: ECC patents?
On Wed, Sep 14, 2005 at 12:18:14PM +0300, Alexander Klimov wrote: http://www1.ietf.org/proceedings_new/04nov/slides/saag-2/sld9.htm: What is Really Covered o The use of elliptic curves defined over GF(p) where p is a prime number greater than 2^255 when the product satisfies the Field of Use conditions o Both compressed and uncompressed point implementations o Use of elliptic curve MQV and ECDSA under the above conditions This hints that indeed only some particular curves are patented. Not quite. I understand the agreement is about using MQV and other patented stuff, but limited to certain curves. This alone does not necessary imply that the *patent* situation is different for prime fields and binary fields, or for different field sizes -- it just means that the *license* to the relevant patents has been restricted accordingly. Scott Vanstone reports that Certicom would have charged more for including binary curves as well and this is why they were left out (for now). The OpenSSL team, cowards that they are, omitted MQV and other stuff that would infringe on patents. MQV is a useful protocol, but clearly covered by patents. OpenSSL does support both prime curves and (more recently thanks to the Sun contribution) binary curves, but without point compression for binary curves since this would be another patent issue. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
