OpenSSL Gets Cryptography Gift From Sun 217
Kataire writes "C|Net posted this story about how Sun Microsystems' has donated 'elliptic curve' encryption technology, (developed by Whitfield Diffie of Diffie-Hellman public key fame) to the OpenSSL project. This potentially means better encryption for lighter-weight systems such as PDAs."
Great! (Score:4, Funny)
Re:Great! (Score:4, Funny)
You mean right now you let *your* palm *date* your friends? Ewww....
Re:Great! (Score:2)
think about it...
Re:Great! (Score:2)
Re:Great! (Score:5, Interesting)
If strong encrypted money tokens were to be implemented on a wide scale for, say, Palm PocketPC, Zaurus, and maybe a special purpose StrongARM device, you could expect to see a cheap widespread secure electronic payment mechanism that you can use for micropayments.
Aside from the novelty of buying lunch with your PDA, this could be the next step towards truly secure electronic transfers. You can say goodbye to corporate privacy violations when you can pay for your online goods with secure anonymous electronic cash.
Imagine paying your peers in a P2P system for MP3s/OGGs/whatever. Providing fat bandwidth for P2P would be a potential money-maker, not merely a labor of love. Throw in an anonymizing protocol and you're selling MP3 bandwidth online securely and untraceably; the RIAA couldn't shut you down, because there'd be no way to figure out who you were.
That's the power of widespread strong crypto, especially in small devices.
Re:Great! (Score:3, Interesting)
Double Funny (Score:2, Funny)
Actually, this can be taken in more than one way, especially since "palm" isn't capitalized.
Is this the same as featured before? (Score:1)
Re:Is this the same as featured before? (Score:1)
Re:Is this the same as featured before? (Score:2)
If you mean the recent article in the last week. No.
The recent
It's academic in that it is not possible to break (at present time, and oh the next hundred years) in real-life.
Re:Is this the same as featured before? (Score:3, Informative)
No... But there is a distributed project [nd.edu] out there working very hard to crack it - but so far elliptic curve encryption holds out...
By the way, Ars Technica has a team [teamvodkamartini.net] working hard on this project, and they I'm sure they'd like some help... ;-)
It's not really that surprising (Score:5, Insightful)
Re:It's not really that surprising (Score:2, Interesting)
Sun should watch out for blowback from these rebels. Look what happened when the US CIA funded, armed, and trained Saddam Hussein and Usama bin Laden.
In all seriousness, if the open source desktop succeeds, who is more likely to profit, Sun or Dell?
Re:It's not really that surprising (Score:3, Funny)
Re:It's not really that surprising (Score:2)
Re:It's not really that surprising (Score:2)
WE DON'T LIKE BAD SOFTWARE.
Re:It's not really that surprising (Score:1)
Re:It's not really that surprising (Score:4, Interesting)
No. I think it this move was designed to improve Apache's security and make it a greater e-commerce tool on solaris( and unix). Sun relizes that more sun webservers use apache then Iplanet so they are donating the code to openssl since apache uses it by default. And not to just attack Microsoft. However I do question the timing since newly discovered ssl flaw recently in IIS/IE is making headline news and CIO's nervous.
Something like this may have an impact in e-commerce purchasing decisions.
Re:It's not really that surprising (Score:2)
Personally, I think the timing is just loverly. Not only is the hole patched pronto and openly, but the machinery is being put into place so that Apache on Solaris (and others of course) can actually be trusted.
At this point I'd be extremely leery of the ultimate security of Microsoft software.
Re:It's not really that surprising (Score:4, Interesting)
I'll probably get modded out of commision for this, but I just really get tired of misspellings.
Even though I was on the netscape side, and got laid off, I'm still loyal to iPlanet. They gave me my start in the IT world (head Sysadmin for iPlanet Learning Solutions), and I can't thank them enough for it.
Re:It's not really that surprising (Score:2)
Ugggh.. (Score:2)
Re:Ugggh.. (Score:2)
Shouldn't this be placed under a different section (Score:4, Interesting)
Nonetheless, it is great to see Sun contributing back to the community.
This does bring up one question in my mind though... could this be used in SSL acceleration cards to improve the effiency of the SSL 'processor' (i.e.: keep the same performance level while reducing the amount of power necessary)?
Re:Shouldn't this be placed under a different sect (Score:1)
Now let's see if we can get the to contibute Solaris to the community.
Re:Shouldn't this be placed under a different sect (Score:1)
Re:Shouldn't this be placed under a different sect (Score:1)
Re:Shouldn't this be placed under a different sect (Score:2)
Unlikely in presently deployed accelerator cards, since AFAIK most (Rainbow CryptoSwift [rainbow.com] and nCipher [ncipher.com]) are based on custom hardware chips (FPGA and the likes) which do mainly RSA key setup which is the really slow part of establishing a SSL session. I believe several of the cards do not even do any symmetric (i.e. RC4, 3DES) acceleration because it isn't worth it.
Re:Shouldn't this be placed under a different sect (Score:1)
Re:Shouldn't this be placed under a different sect (Score:4, Interesting)
OpenSSH is a baby of openBSD, and OpenSSH depends on OpenSSL.
The Eliptic curve stuff was donated to OpenSSH team, not the OpenSSL group. So dreaming about this in your ssl accelerated card of the future is a bit silly. However, if openSSH team open sources the tech, and that tech is under bsd lisence, then maybe it will work its way down into the chip makers crypto designes.
Re:Shouldn't this be placed under a different sect (Score:1)
Blockquoth the News.com article [com.com]
Re:Shouldn't this be placed under a different sect (Score:2)
And there are lots of [sonicwall.com] companies that [cacheflow.com] sell stand-alone [cryptoapps.com] SSL accellerators. [nortelnetworks.com]
Wrong. OpenSSL != OpenSSH (Score:5, Informative)
Not quite.
OpenSSL is maintained by OpenSSL core members: Ralf S. Engelschall, Ben Laurie, Mark J. Cox, Dr. Stephen Henson, and others developers. [openssl.org]
OpenSSH was written by OpenBSD members (Theo de Raadt, Niels Provos, Markus Friedl, Dug Song, and others). OpenSSH uses OpenSSL as a cryptographic library source (it is highly optimized for many processors).
When cryptography is outlawed, (Score:2, Insightful)
Kudos to Sun (Score:1)
Another fine donation by Sun. Congratulations to them for the offering.
Good for more then PDA's (Score:3, Insightful)
Re:Good for more then PDA's (Score:1, Informative)
Huh? "Using the Quantum Computer to Break Elliptic Curve Cryptosystems" [nec.com]
Re:Good for more then PDA's (Score:5, Informative)
Re:Good for more then PDA's (Score:2)
You must be new here. Talking out of your ass is a very important part of social development here at Slashdot.
wrong, wrong, _wrong_ ! (Score:3, Informative)
In fact, it has and can be easily shown that by solving "the factoring problem" (as it's oh-so-vulgarly put) or the discrete log problem of classical public key cryptosystems, one solves EC's. The problems are extensions of one another, and the solution to one is trivially deducible from the solution to another.
your statement was like saying "unlike Webster's Dictionary, the Oxford English Dictonary has no words in it" - pure and utter nonsense. gibberish.
All ECC's are (in boiled-down essence), is a Discrete Log problem on a cubic whose solutions are confined to a torus. (i.e. 'elliptic curve').
while it's true that the keysize needed for secure ECC is much, much smaller and increases much much more slowly than either DL (discrete log) or IF (integer factorization) [both of which are essentially exactly the same] systems, this has to do with the way the field is set up and how the keys correspond.
elliptic curves? (Score:1)
Re:elliptic curves? (Score:1)
Re:elliptic curves? (Score:3, Insightful)
SSL and PGP (or preferrably the newer OpenPGP [openpgp.org]) standard both use a hybrid scheme which uses both asymmetric and symmetric encryption algorithms.
If you mean could elliptic curves schemes (ECDLP, ECDSA, ECDH) be used in OpenPGP as well as SSL/TLS; then yes as long as it was added to the OpenPGP standards [ietf.org] which I don't think includes ECC yet but has spaces reserved for future ECC use.
Taniyama-Shimura conjecture (Score:2)
so now (Score:1)
Re:so now (Score:2)
Offering from large companies (Score:5, Interesting)
Re:Offering from large companies (Score:2)
The gesture isn't alturistic, I'm sure. Still, everyone benefits. Sun gets kudos for helping a project that is held highly by everyone else, and the project gets another algorithm under its hood.
Re:Offering from large companies (Score:2, Interesting)
Well, any corporation can be beat if they screw up. Sun's stock hovers around 3 and Oracle is scraping by at 9. MSFT would have gone down with them had they not been aggressively buying their own shares to prop up the price. ( I fear they too will tank in time--yay)
Rather, open source developers can't be beat. You can't sue them, fire them, or force them one way or another. If one gets disgruntled about life and everything, five more rise to the occasion (with appropriate amount of bickering--but no ones dies of bickering... ni! ni! ni! ).
This, I think, is a perfect case of: Since they (the Corps) can't beat us (the OS Devs) they're joining us.
I just hope we don't jump on the bandwagon wholesale. Their evil ways are insidious, promising riches and glory,capitalism style, but lead straight down the Road to Perdition to the Bankruptcy Court.
Harken thee: inspect the mouth of the gift horse. (translation: watch your back OSS)
Re:Offering from large companies (Score:1, Interesting)
Sun's views their business as servers, and big iron, places where linux is not really making such strong inroads. Mega-servers are still dominated by big iron.
So, having as much client competition as possible makes sense. So, good crypto on the client increases client competition, and weakens Microsoft's hold on it.
All Sun really needs is for linux to be a serious client competitor. Then the focus shifts to the server, where Sun dominates other companies.
You could see Microsoft use this strategy when they maintained rights to DOS after licensing to IBM. They licensed DOS to all hardware manufacturers, to make them compete. Hardware became a tough business, and Microsoft got a monopoly.
it's all strategy (Score:3, Insightful)
Not all such gifts are useful for the recipient, and some are genuinely harmful to the interests of open source users. So, do look a gift horse in the mouth, or you may be stuck with large vet bills otherwise.
This one seems harmless if it is on unpatented technology, or if the patents are free for use by open source.
Re:Offering from large companies (Score:4, Interesting)
denegrating this contribution as if it's a new position sun isn't very fair to their company or their developers.
Certicom SecureMemo? (Score:1)
Unfortunately, I think Certicom pulled the app from their site. Nice app.
Re:Certicom SecureMemo? (Score:1)
your drawing was likely just random input.
Re:Certicom SecureMemo? (Score:1)
Re:Certicom SecureMemo? (Score:1)
I'm no expert, but my guess would be that the "drag your stylus about" part was almost certainly just random number generation, and the crypto just, well, plain crypto...
Elliptic Curves refer to a set of mathematics... Here's a FAQ! [inria.fr]
Re:Certicom SecureMemo? (Score:1)
Unless of course s/he means it...
Please say it's patented.. (Score:2, Flamebait)
Or... was that a rather evil thought? I'm not sure anymore, I'm so blinded by my zealotism.
Re:Please say it's patented.. (Score:2)
Re:Please say it's patented.. (Score:1)
See our helpful friends (ahem) down at RSA [rsasecurity.com]. Dan Bernstein has more here [cr.yp.to].
Re:Please say it's patented.. (Score:1)
C
Nice - but is it really necessary? (Score:1)
The article cites that current encryption technology is based on 17th and 18th century mathematics - so is quite a lot of other things that work very well indeed. Mathematics don't deteriorate.
Of course this is a Good Thing (tm), but I honestly don't think that many people will ever notice a difference.
Re:Nice - but is it really necessary? (Score:2)
Most high end PDAs do for file encryption, but as increased demand for WTLS (Wireless TLS), "wireless speed" encryption for high speed GPRS/Bluetooth/802.11/1X networking applications. Applications like online wireless betting or online wireless reservations need better (read: quick) security in PDAs and mobile phones, which have less powerful processors.
Re:Is speed really all that necessary either? (Score:2)
I think a 16 MHz ARM processor would only be in a "high end" smart phone, or a PDA and not your mass market average cell phone.
ECC makes a big difference for low cost mass market microprocessors. Think 8 or 16 bit, less than 12 MHz on average. 1024 bit RSA encryption can take up to 1 minute in such environments.
Burning Cell Phone! (Score:2)
I think a 16 MHz ARM processor would only be in a "high end" smart phone, or a PDA and not your mass market average cell phone.
What would a "mass market average cell phone" need with fast public-key encryption? Can't it just authenticate with the cell tower, grab a symmetric key, and then just encrypt voice with AES[1] based on that, possibly grabbing new symmetric keys during non-talk time? Wouldn't the more advanced "Burning Cell Phones" [nofx.com] that run apps other than voice and simple games be essentially PDAs with a fast processor anyway?
Think 8 or 16 bit, less than 12 MHz on average.
So you're talking half the power of a GBA. (The GBA is 32-bit with a 16-bit data bus, clocked at 16 MHz.) How does RSA computation scale with respect to keylength?
[1] Yes, AES been theoretically attacked down to 96-bit, but 96-bit is still considered quite "strong" for symmetric encryption. It has taken nearly four years, and one of the world's biggest clusters still hasn't broken a 64-bit key [distributed.net].
Just what was donated? (Score:2)
8-10 years from now? (Score:2)
Supposedly, this offers encryption with less computational demand. And, supposedly, it's not going to be in use for 5 to 10 years.
If that's the case, my quesion is this: Why bother? Moore's law says that in the 10 years that it will take to get this implemented, CPU's will be *64 times faster* than they are today.
Just think: "Wow! With this new encryption technology, encrypted 100 megabit networking only takes 0.05% of my processer instead of 0.1%!"
steve
Re:8-10 years from now? (Score:1)
Re:8-10 years from now? (Score:2)
Re:8-10 years from now? (Score:2)
You're half right, half wrong. Moore's law DOES deal with transistor count. However, it says that it will double every 18 months, not every 6 months. (originally, it was 24 months, but later revised.)
In practice, however, the actual computational power has been doubling about every 18 months as well.
As evidence, look at where we were 10 year ago: The big, bad processer to have was a 33 MHz 486. Today's high-end processers have MORE than 64 times the computational power of the 486 of a decade ago - and there's no indication that we're not going to keep on track for another decade.
steve
Re:8-10 years from now? (Score:2)
Re:8-10 years from now? (Score:1)
Re:8-10 years from now? (Score:2)
Look at the newest, fastest Athlons - they produce less heat than considerably older versions. Why? Smaller manufacturing process. And that's going to keep on going...
steve
Re:8-10 years from now? (Score:2)
Supposedly, this offers encryption with less computational demand. And, supposedly, it's not going to be in use for 5 to 10 years.
I know the article was a bit low on facts (and more of a big ad for Sun), but you really need to do some Googling before you post. In fact, ECC is used for key agreement and sometimes authentication but almost never encryption.
If that's the case, my quesion is this: Why bother? Moore's law says that in the 10 years that it will take to get this implemented, CPU's will be *64 times faster* than they are today.
It makes a big difference. Public key operations are slow by nature. When you decrease the keylength, not only do you have fewer bigint multiplies to perform, but the real key is that you are multiplying smaller numbers. Keep in mind that in 10 years you will also need to use longer keylengths to be secure.
Just think: "Wow! With this new encryption technology, encrypted 100 megabit networking only takes 0.05% of my processer instead of 0.1%!"
Maybe in 10 years your networking apps will require 64 times as much bandwidth. Anyway, it's a moot point since no one uses ECC for encryption. ECC is used mostly for key agreement, where practical key lengths are limited by how long you want to make the user wait. A Diffie-Hellman operation with a conservative key length could take as much as 5 seconds of CPU time on a Pentium 2. The equivalent ECCDH negotiation might take only 1 second. Surely that's a significant enough difference.
-a
Certicom has done commercial ECC for years (Score:2)
Re:Certicom has done commercial ECC for years (Score:1)
ECC algorithms have all sorts of submarine patents and prior art that have prevented widespread adoption. Sun's donation does not change that.
Too bad, coz ECC is way cool. I did a digital signature app with Certicom ECC that resulted in 42-byte signatures.
Securing edge of network devices (Score:2, Insightful)
As it stands now, having a wireless network could be a blessing. Information available at your finger tips. PDAs have never been a strong focal point for security in my experience. It will be great to see a network that can be truly encrypted end to end.
Now if only the user friendliness of this made it so that even the ordinary citizen could use it.
Bush's advisor present, official government suppor (Score:5, Funny)
The NSA can already crack it.
Why don't they release a OPENSSL patch for Cobalts (Score:2, Offtopic)
Re:Why don't they release a OPENSSL patch for Coba (Score:2)
But I'm also not necessarily representative of most COBALT users. People who CAN build from source are generally not the target audience of the machine. They BOUGHT a Cobalt server as an appliance, which is what SUN markets it as. SUN says not to ever touch the CLI, as "The GUI does everything you need".
People buy a Cobalt from a big name vendor so they get the stability and resource-friendliness of Linux with (theoretically) the SUPPORT (in terms of patches and making the software easy to use and documentation) of a big name vendor.
So that's the problem.
(I love trolls who are such wizards about all this, but still post anonymously)
Whitfield Diffie did NOT invent ECC (Score:5, Informative)
Elliptic curve cryptography was indepentantly
invented by Neal Koblitz [washington.edu], Professor of Mathematics at the University of Washington and Victor Miller who was then at IBM.
(Source [certicom.com])
Whitfield Diffie is Sun's chief security officer, and co-invented public-key cryptography.
Merkle invented public-key cryptography (too) (Score:5, Informative)
Actually, Ralph Merkle invented public-key cryptography (too). Merkle's article was SUBMITTED first, though the Diffie-Hellman article was PUBLISHED first while Merkle's was still going through the review process.
Not to disparage any of 'em. Merkle and Diffie & Hellman both invented it separately.
And for you people who follow Nanotech and/or Cryonics, yes it's THAT Ralph Merkle (who didn't invent either cryonics or nanotech, though he does much great work to advance them).
James Ellis and the CESG (Score:2)
Back in the '60s, it had been invented at GCHQ by James Ellis for use by the British Secret Service. Unfortunately, due to the Official Secrets Act, Ellis was forbidden to publish or discuss his discovery.
The organisation that Ellis worked for, CESG, are on-line - you can check out their site here [cesg.gov.uk].
Here's [cesg.gov.uk] a link to a page explaining their input into Public Key Crypto.
I'd first heard about Ellis' work in Simon Singh's book, The Code Book. James Ellis seemed to be a very quiet, modest person. It's a shame that his name isn't to the forefront when we think of Public-Key crypto. Credit where it's dueRe:James Ellis and the CESG (Score:2)
Sounds like something 'the tick' would say (Score:4, Funny)
not to sound bitter... (Score:2, Interesting)
My crypto lib has supported [non-P1363] ECC crypto since quite sometime now. Big deal.
http://libtomcrypt.sunsite.dk
or
http://tom.i
I use ECC in the traditional ElGamal method without standard packet formats. But the idea is the same...
Tom
Re: algorithms vs. applications (Score:2, Interesting)
Your library is nice, it is portable C with tons of algorithms implemented. Test vectors. Most algorithms even have decently optimized implementations which is a plus.
But you lack protocols which are necessary to securely implement applications.
Using 3DES or AES is stupid if the application developer uses ECB (Electronic Code Book) mode of operation because it's faster and simpler. The application developer doesn't know that you need a HMAC to ensure intergity. What about replay attacks? Cut-and-paste attack?
I don't think you even have secure message padding for RSA implementation.
You have an interesting library of algorithms, but its is AFAIK lacking the "glue" to make it more useful than OpenSSL (which is ported and tested on many platforms, and heavily optimized assembly).
So to develop secure applications I will continue to use OpenSSL rather than LibTomCrypt. It is less work for me, simple as that. If you expand your work, that will end my complaints, and we'll both be happy.
Peace.
Re: algorithms vs. applications (Score:2, Interesting)
In fact unlike the CryptLib and OpenSSL design my library is fully modular which means the OFB code for instance is not tied to one cipher. If you examine CryptLib [and from what I have seen of OpenSSL] they have implemented one OFB [etc] routine per cipher....
I agree though that protocol support is a good idea but thats not a be-all either.
Most protocols don't fully specify your PRNG/RNG source or how you should lock memory, store things on disk, etc...
In otherwords you can comply with say PKCS #1 and still have an insecure application.
Also unlike OpenSSL my library builds out of the box on virtually every GCC platform without configuration or patching. It even works on my Gameboy Advanced without changes!!!
In the long run I agree. I do plan on adding things like PKCS #1, P1363, etc... but in the short term I am more interested in getting mature, well documented primitives.
Tom
License? (Score:4, Interesting)
Not such a big deal, you might say, but there are two big problems with this: 1) It's incompatible with GNU GPL, so no straight GPL software can use OpenSSL, and 2) it causes huge practical problems [gnu.org].
Theses issues are a big [debian.org] problems [debian.org] for [debian.org] Debian [debian.org], in particular.
I'm really unclear what Sun is 'gifting' here... (Score:2)
sun labs (Score:3, Informative)
Three types of elliptic curves (Score:3, Insightful)
I wonder which curves can be used with the code offered by Sun.
Sun FAQ (Score:2)
http://research.sun.com/projects/crypto/Frequenly
It includes technical information and answers questions some people had about licensing.
Re:If only Pocket IE supports it... (Score:1)
Re:If only Pocket IE supports it... (Score:2)
Re:Get some PRIORITIES! (Score:1)
Re:This rocks (Score:1)
Re:NeXT, did NOT invent ECC. (Score:4, Informative)
Sorry, Ellipitic curve cryptography was invented independantly by Neal Koblitz, Professor of Mathematics at the University of Washington and Victor Miller who was then at IBM.
(Source [certicom.com])
Re:Why is this significant? (Score:3, Interesting)
ECC uses smaller keys, which is suitable for very small networked devices like network appliances, that use cheap (<$1) 8-bit microprocessors with very small amounts of NVRAM.
Is eliptic curve cryptography actually faster than RSA?
Yes, which is the major advantage over RSA, more important in most applications than the storage of smaller keys. I don't know exactly but I estimate in the area of 10 to 100 times faster for "equal" level of confidence in security.
And if it IS faster, wouldn't it be much more useful for web servers than for PDAs?
Think mobile phones, or cheap network household appliances with 8 and 16-bit microprocessors with clock speeds less than 12MHz. It also means lower power comsumption which is important for most battery powered devices.
Re:BSD?? (Score:2, Informative)