> Dr. Schatten, who was to have led the organization's
> board of directors, says he is now severing collaboration
> with Dr. Hwang, due to questions over the source of human
> eggs used in a 2004 cloning project, and errors in a 2005
> paper coauthored by the scientists. A 2004 news report
> in the journal Nature said at least one female laboratory
> worker had provided eggs for the project, an allegation
> that Dr. Hwang has denied on several occasions.
Is it just me, or does it look like Schatten didn't have a problem with the forced collection, only starting to sever ties (note the tense there: "is now severing", ie, he hasn't finished?) after problems come up with a paper?
Well, there are a few things you maybe do not know about scientific collaboration projects.
When people from different institutions work together, they do not always know all the technical
details of the work of each other. There is trust about details which are not of competence of the
others.
For example I am writing a paper with a colleague from Canada, where
I am supposed to implement a specific algorithm he wrote: He does not need to see my code, he need
to see the timings. FWIW, I could have asked a "slave" to write it: I did not, but if I did and I did not acknowledge this, this would have been unethical.
Hence, one can assume in good faith that Dr. Schatten did not know the source of the eggs when the
paper was written (presumably not later than early 2004). Then the paper was submitted and accepted for publication - scientific journals have a big backlog and the paper was supposed to be in print in 2005. It could have even been that online publication was in 2005 and print in 2006, I did not check this.
If the Nature report was published in 2004, it is simply impossible that the paper was not yet written and that
it appears in print now. The paper must have been written before the allegiations have been made.
Now, of course it is entirely possible that he knew what was happening and he did not care about it until the source of the eggs was made known. I have seen worse in the scientific community. Somebody else mentioned prostitutions in this discussion: I have seen entire academic carreers built around a vagina...
Not to speak of the fact that the iMac comes in a very compact package.
Sadly, most people will only see "oh, 1.9 Ghz, it is not even at two" and then read the "3000+" marking on the Athlon CPU and say: shit, the iMac has only 60% of the speed, and still costs more! (and it is not expandable, and it has a one buttone mouse, unless you point out that the mighty mouse is included).
The thing that should really kill RSA is that it has no advantages whatsoever over Rabin besides being slightly simpler, and it has several important disadvantages, particularly the absence of a provable relationship with factoring.
There's also a bit more investment in RSA, there are more fielded products with RSA built-in, and most importantly of all, the patents expired. Did not check the patent situation on Rabin.
I also prefer Rabin over RSA, but both suffer from the same problem: the subexponentiality of solving algorithms.
There are other techiques, ECC is not that complicated, and also codes are not that difficult to implement. I am fond of HECC because it is the main object of my research in crypto at the moment.
But people still stick to technologies that are similar to the old, known ones. For example, just to stick to the discrete logarithm in finite fields, now egregious colleagues are researching algebraic tori a lot. Still, they will suffer from the same problem as RSA or Rabin or the DL in prime fields: subexponentiality of solving the underlying problem will lead to key explosion sooner or later with respect to ECC.
On the other hand Arjen Lenstra made a good analysis that the field element compression techniques will provide a good method for the next few decades. Of course, until there are no new breakthroughs in breaking such schemes (and it seems more likely that people will make a bigger advancement in this area than in the algebraic curve setting).
Let us not forget that ine of the aspects that keeps RSA afloat is the usage of short public exponents. These guarantee that RSA encryption can be done in time quadratic in the key size, whereas ECC and other methods are cubic (RSA decryption is cubic time). You might like this or not, but this is not that bad, even though, as you mentioned, why use an asymmetric system to encipher a large amount of data? You just use it to agree on a key (or to encrypt it) for symmetric method.
Actually, reading on, it looks like the author really doesn't have a clue. At one point he suggests using RSA in place of DES. Even most Slashdot readers know that in practice, when you use RSA for encryption, you use it in conjunction with a symmetric encryption algorithm.
Exactly, and this because the asymmetric part (RSA) is very slow compared to a symmetric algorithm. So we use the asymmetric part only to perform a key agreement protocol, in other words to agree on a new key to be used in the following symmetric part.
In fact, RSA is starting to age quickly, and there are far better alternatives.
Since there are subexponential algorithms to solve the factoring problem, RSA key sizes will increase a lot in the next years, and
will soon be in the thousands of bits.
There are many other choices for asymmetric schemes, and there are groups for which no subexponential attacks in the key or block size are known. These should be used in conjunction with a symmetric scheme such as AES.
Very attractive today are elliptic curves (ECC endorsed also by the NSA, no less [*]) and low genus hyperelliptic curves (HECC). a 140 bit ECC or HECC key offers security equivalent to 1024 bit RSA. The bandwidth advantages are evident, and at this level speed is of the same orged of magnitude, with an advantage of ECC and HECC over RSA.
Arjen Klaas Lenstra wrote a nice contribution
in Key Lengths to
The Handbook of Information Security. If you cross-reference with the paper he wrote with Erik Verheul on Selecting Key lengths, you will see that 200 bit ECC and HECC should be equivalent to about 4000 bit RSA security, which should be a good estimate for a good security level for the year 2050 - the NSA is proposing to use 571 bit ECC, which provides security equivalent to about 15,000 bit RSA. Now, creating good istances of RSA moduli of that size is lengthy, and at the same time the cryptographic operations become extremely slow. ECC and HECC mantain good speed though.
Multivariate quadratic systems can be used to construct both secure and efficient public key schemes. Their main problem is the key size,
which can easily go to several hundreds of kilobytes. But, the attacks are exponential in the block size, which, for the so-called oil-and-vinegar schemes, remain well bounded. They are very fast and are nice for exchanging keys for the symmetric scheme following the asymmetric part.
Lattice-based systems, NTRU (which can be interpreted as a special lattice based system) are also nice alternatives, but it is difficult to construct secure instances. Code-based systems are vey nice, but the main advantages are short signatures, hence their main application is outside the scenario considered here.
[*] The E.U. is endorsing elliptic curves, too. A strategic project, AREHCC, did extensive Advanced Research on Elliptic and Hyperelliptic Curve Cryptography. The web site of the project, now ended, is still up (http://www.arehcc.com/) and there is a bit of interesting material. A book has been just published on the subject, by authors that worked for AREHCC:
R. Avanzi, H. Cohen, C. Doche, G. Frey, T. Lange, K. Nguyen,
and F. Vercauteren.
Handbook of Elliptic and Hyperelliptic Curve Cryptography.
Chapman & Hall - CRC Press. 2005.
This is a mammoth book, and for a leaner introduction, with less theory but perhaps better for practitioners one can get
D. Hankerson, A. J. Menezes, and S. A. Vanstone.
Guide to elliptic curve cryptography.
Springer-Verlag, Berlin, 2003.
a very well written introduction. Then there are the two books edited by Blake, Seroussi, and Smart, on ECC. The latter titles however lack a treatment of HECC.
A follow-up project to AREHCC (and NESSIE), called ECRYPT
(http://www.ecrypt.eu.org/), has also considerable resources devoted to alternatives to RSA - including ECC, HECC, and all the other alternatives mention
Yes, you are. Your entire argument is based around the idea that without using TCPA, Apple is doomed to have their magnificent operating system ripped off.
Absolutely not. TCPA is ONE way of achieving this, and until now, we have NO evidence whatsoever that it will be used for anything else. There is clear evidence that it will be used to lock the OS to apple hardware. And, NO I am not tweaking the financials. The bulk of the income still comes from hardware sales.
The only way Apple can "protect" their operating system from being run on other hardware is to include Trusted Computing?
I did not say that.
How far will you twist and turn to avoid the truth?
I am not twisting anything.
We are discussing here the fact that the presence of this chip can be used to lock the Mac OS on Apple hardware. Apple said this. I also mentioned that this is only one way of achieving this, only one of many different ways.
How about the fact that Apple makes its money from people buying its systems for the lack of hassle?
Please reformulate this sentence in English... why should Apple NOT be allowed to make money from hardware sales?
You mean if Apple just included a simple BIOS check, aunty Doris might purchase a PC clone with Windows XP on, download a hacked version of OSX (with the check removed) from P2P, install it and gloat over Jobs' loss of cash and lack of vision in not implementing a "Trusted computing" infrastructure that would have prevented this.
No, I am not saying this. Anyway, it is clear to me that YOU want to use Apple's fruits of labour without having to support Apple's development. In other words, to me you are angry just because you fear you would not be allowed to be a thief.
There's a different problem. What other uses that infineon DRM chip may have. But you say something quite wrong:
How deluded are you? If you seriously think this is purely to control the distribution of OSX, then Apple zealots are more witless and crazed than I thought. You talk of "profits"... and then ignore the fact that Apple is making most of its money on iTunes and possibly its forthcoming video versions... all of which will be big future users of TCPA once it is established.
Apple currently makes money from hardware, not from iTunes and iPods. Please check the facts. iTunes and iPods are giving them mindshare (at the moment), and I do not have your crystal ball.
When the Mac TPM was pure speculation, there were several hundred posts here suggesting alternate theories: custom chipsets, custom firmware, etc. Reality is slowly seeping in that MacIntels will be Dells with a dongle attached.
And how would an apple machine with a custom chipset any different?
It would be in fact EASIER to modify the (open source) kernel to avoid checking the DRM chip instead of modifying it to work on a different architecture. In both cases the software installation and update mechanism can check if the machine is Apple's or not.
Apple chose the road of less effort to make it difficult to run their OS on other hardware. A road that allows them to use off-the-shelf hardware components more easily, BUT this does not mean that apple hardware will be like "Dells hardware with a dongle attached". There are many different PC brands and luckily only a few have poor build quality as Dells. Look at their use of integrated graphics on final products, or at the extremely poor and faulty laptop screens - 30% of the screens of Dell laptops sold to universities and schools, in my experience, develop white spots within a few months due to poor assembly and quality checking: not the same with Apple.
The message that has to go out from here is simple and the same one that should go out to any software/hardware company that involves itself with this anti-customer bullshit: Don't buy Apple.
There's no doubt that the poster you are replying to has missed something. But it seems to me that you also miss something. Apple is a hardware manifacturer. Why should you be able to buy Apple's OS and run it on other hardware, if it is NOT intended for that use? It is not like having an obscure data format for your data, a la Microsoft. It is not giving up the right of accessing your data the way you want. Apple is a hardware manifacturer and they have an OS for their hardware. The OS is there to drive customers to their hardware. Only a part of the development costs comes from OS sales, the bulk of their money comes from hardware.
Now, you would like to have Apple continue to develop their OS but you want to strip them of their main income source by allowing the OS to be installed on non-Apple hardware. It seems to me that the word ``idiot'' can at this point applied also to you, not as an insult, but in the ethimologic meaning: from the greek ``that cannot see'' (i-diot, then the word entered latin, old french, and finally came to english).
You propose to boycott Apple until they agree to give up on income, so that you can use their products in a way they are not envisioned. Sure, bankrupt firms develop their software actively...
Learn programming and start contributing to GNOME development instead, and do not complain, please, if Apple has some features you are not able to implement...
Konfabulator had is right with widgets being able to stay on the desktop all the time
Well, you can do the same with the Dashboard widgets too.
The way of doing it is by activating Dashboards "debug mode",
and has been described on countless forums on the net. You can find some information at the following site: http://www.tigerwiki.com/index.php/Dashboard
Why would Apple design a 2 button mouse? Is that not insane? Wouldn't it make more sense to design at least a 3 button mouse with a wheel? What would really be gained by simply adding a second button?
I am a Mac user and I can tell you: three button mice scare me! If I have to be forced to use multibutton mice, then they should train me IN SMALL STEPS!:-)
Roberto
PS: seriously speaking, I have no need for additional buttons on the trackpad, since the ctrl key is already very close to my fingers, but the additional buttons on the mouse can result handy.
In fact, I believe that ECC is a safe method, until quantum computers are built - in which case all methods based on the discrete logarithm problem in abelian groups are killed.
The discrete logarithm problem (DLP) is the following one:
Given a group G generated by an element g, and a second element h of G, find an integer t such that g^t=h.
It is clear where the name discrete logarithm comes from: One could (with some abuse of notation) write that t is the logarithm of h to the base of g. This name is used even when the group G is written additively, i.e. the operation is not a "multiplication" but an "addition" and the "exponentiation" g^t is written as t times g (t.g), hence we speak of "scalar multiplication".
So the question remains: Have they found a successful attach on ecliptic curves, or have they finally seen the light and realized that strong encryption is good for society?
I doubt that they found a successful attack.
In fact, I believe that ECC is a safe method, until quantum computers are built - in which case all methods based on the discrete logarithm problem in abelian groups are killed.
They also proposed ludicrously large parameters in some cases. They know that somebody is going to use them anyway, hence it is better to suggest the same also to US government agencies and industries. Moreover, they bought the rights to some patents from Certicom (I got the news the same day the deal was closed), hence they can charge royalties.
I believe that the european community should use methods which provide the same level security but are not encumbered by those patents. Hyperelliptic curves and trace zero varieties, apart from the scary names:-) are good candidates. With suitably chosen parameters you can attain the same level of security, better performance and live with no legal strings attached.
they claim they've reduced the complexity from O(q^{1/2}) down to O(q^{1/4})... In practical terms most serious ECC implementations are using q in the order of 2^200 or more
Say you're using a 200-bit ECC key. Now your 2^100-step brute-force is down to a 2^50-step brute-force. Six years (four Moore doublings) ago, EFF and distributed.net brute-forced another cipher's 56-bit key in under 24 hours.
The 2^100-step brute force is down to 2^50 brute force IF a few bits of the secret key are already known, or obtained by some other means. A good implementation is safe. It is not the first time that partial knowledge (a few bits) of a secret allows for a "cascade" effect, that permits to recover more information in less time. Per se ECMQV is not broken.
As a grad student studying crpyto I think I can answer some questions out there
...
In response to another question above:
In crypto we work with these curves over a finite field, which is basically a set of numbers of the size q=p^n, where p, the characteristic, is a prime. We either work with p=2 and n~163 or p = a 163-bit prime and n=1. Elements in the finite field of p elements looks like {0,1,2,..., p-1} and you do arithmetic modulo p. If you work in the finite field of 2^n elements, the elements of the finite field look like polynomials with degree n with coefficients either 0 or 1. The size of the group that we work with and do the key exchange and everything in has size in the range [((sqrt(q) - 1)^(2g), ((sqrt(q) + 1)^(2g)], so about q^g. That's why hyperelliptic curves are nice: with genus 3 curves, your key size is a third of the length of the key size for elliptic curves.
OK, you got some things right, other less so.
With genus 3 curves you DO NOT get key size equal to a third of the length of the key size for elliptic curves. What you get is that the FIELD over which you define the curve and implement the arithmetic gets smaller! To one third. The key has a size equivalent to 3 field elements, hence has the same size as with EC.
If you take into account the attacks by Gaudry, Theriault, Gaudry Thome and Theriault... then already for genus 3 you have to use a slightly bigger key, but 5 to 10% more bits. Not a big deal, and also the field size increases accordingly, so it is a few bits more than one third that of the field used for an elliptic curve.
The advantage is that the operations are performed on smaller fields. On the other hand there are many more of them (the number of finite field operations to operate in the jacobian variety of a hyperelliptic curve of genus g is in practice between O(g^2) and O(g^3), asymptotically closer to the second bound).
This means that the multipliers in the arithmetic unit can be made smaller, making the hardware cheaper - or requiring less multiprecision arithmetic in software - but the software implementing the formulae for the oeprations gets more complicated. It is a balance of costs and performance.
The sweet spot for normal security (160-256 "geometric" bits, where the RSA keys could be defined "arithmetic") is still with the elliptic curves: for larger security (as for the 320 bits used by the german "NSA", the BSI, of the 520+ bits adopted by NSA) the sweet spot are genus 2 HEC (see the papers by Avanzi and Wollinger at CHES [Cryptographic Hardware and Embedded Systems] 2004, for a nice divisor doubling formula in even characteristic see the paper by Lange and Stevens at SAC [Selected areas in Cryptography] 2004). I am a very strong proponent of low genus HEC in odd characteristic (fields of the type GF(p) - the integers modulo p in simplified terms) and of Trace Zero Varieties (expecially those constructed from elliptic
curves - I have nice implementation results and tricks in even characteristic with my student Emanuele Cesena - his Thesis will be discussed shortly).
Roberto
--
_/_/ Dr. Roberto Avanzi, Junior Professor /_/ Faculty of Mathematics and
_/ Horst Görtz Institute for IT-Security
/ Ruhr University Bochum
Of course, if you had actually opened AC's link, you would have seen a paper describing a weakness in ECMQV. Elliptic curves aren't the best objects on which to base an encryption scheme, as they have far too much structure.
Maybe you read the old VISA report that was written to spread FUD on elliptic curves... The goal was to persuade the banks to keep using integers because the RSA patents were about to expire. EC has some patents on it (most can be easily challenged, because there's just too much prior art anyway) but the ones on RSA in the meantime expired.
In fact, the structure of the integers is more transparent and easier to exploit to devise algorithms to solve the main problems on which the cryptosystems are based: factorisation and discrete logarithm problem (DLP) in finite fields (for the non-mathematically literate: integers modulo a prime number and derived structures). Because of this we have subexponential algorithms (the time is subexponential in the bit size of the operands) for solving the DLP in prime fields and factoring integers. But after 20 years of research we still have only exponential time algorithms for elliptic curves and jacobian varieties of hyperelliptic curves of low genus (up to 4).
The structures one should use are:
Elliptic Curves (proposed Koblitz, Miller) over prime or binary fields.
Hyperelliptic curves of genus 2 or 3 (read the papers by Roberto Avanzi at CHES 2004 for implementation details, and the papers by Tanja Lange and Pelzl, Paar for formulae)
Trace Zero Varieties of low dimension (proposed by Gerhard Frey -- read papers by Tanja Lange, Roberto Avanzi, Lange and Avanzi (fortcoming), Avanzi and Cesena, and look also for Silverberg, for theory and implementation details).
For the attacks there is extensive literature. Names to look for for the best attacks on low genus HEC are Gaudry, Theriault (the results are that low genus HEC - this includes EC - are secure).
In a nutshell, EC are as secure as low genus HEC.
Read now
Arjen K. Lenstra, Eric R. Verheul: Selecting Cryptographic Key Sizes. J. Cryptology 14(4): 255-293 (2001)
and you shall see that you need about 160 bits for an EC key size to match 1024 bit integers or finite fields. And 256 bits EC provide the security of many thousands bit integers or finite fields. The numbers are not proportional. If 160 bits EC and 1024 bit RSA provide similar speed, RSA and similar systems fall quickly behind in performance. 512 bit EC operations can still be performed in a short time, by 15.000 bit RSA (the equivalent security level) would require many seconds if not minutes to generate a signature on an embedded device!
Also, a weakness in a PROTOCOL is not necessarily a weakness in the algebraic structure the protocol uses. Many protocols are weak, for example the basic Diffie-Hellman key exchange is not as robust as the Diffie-Hellman mathematical problem. But you can make it as robust as the mathematical problem.
To contact Roberto Avanzi, i.e. me, write the name and family name separated by a dot, followed by the AT sign, the letters
g m a i l without spacing, a DOT and a COM.
Most mobile phone companies in the US are steering towards a flat rate plan to call anyone in the country. I pay $45 a month (taxes included) for Verizon and can call anyone in the US with no additional fees. Quite frankly, anyone paying more than that *is* stupid.
Well, in Europe they introduced a concept called "interconnection fee" to make, as they put it "competition easier". in fact, every provider has to pay something to the provider of a number which is called from his network. So for every call there are fixed costs, which cannot be then covered by a flat rate. New providers are at a disadvantage, since the customers of the other larger networks can profit from cheaper tariffs for calls placed within the network. A customer of a new provider will pay on average MORE to call, and people calling him/her will also pay more... This allowed the big networks to VERY SLOWLY increase the prices up to a crazy level...
This is made worse in Germany by the fact that customers "buy" the cell phone for a small price and then are locked with that provider for 24 months at least.
In Italy this system never got foothold, because, simply, italian customers are smarter than german customers. In italy you buy the cell phone, you pay it full price, you put in it a sim card, and then you phone. The tarifs are always much lower than in Germany - sometimes as low as 25cents (20EUROcents) per minute, even for calling outside the home network.
CRAZY: if I want to call a finnish colleague from germany, and the call is so urgent, and I am out of office, so that I must use the mobile phone, it is much cheaper to do that with my italian prepaid card than with my german contract...
> communicating to people that it's stupid to buy an iPod."
By saying this, he's essentially implying that everyone who owns an iPod is stupid. I don't see any iPod users being persuaded to switch to Napster's service thanks to Mr. Gorog's opinion of them, but considering the size of the iPod's market share, Napster needs to court current iPod/iTMS users, not denigrate them.
Besides that, stupid people are his target market-- who else would think paying $15 per month FOREVER (or your music collection disappears) is a good deal?
Apple in the past ruined itself comparing corporate PC users purchasing IBM equipment to lemmings - stupid creatures just following each other to fall from a cliff. That ad was perceived as offensive and was never aired again.
So this might be a wrong step from Napster.
On the other hand, it is easy to cheat customers, which ARE stupid on the whole. In Germany you have the highest mobile phone tarifs in the world, but people sign new contracts binding them for at least 24 months, and having them paying anywhere between 20$ and 100$ a month, because they get the newest cell phone for a couple of bucks. And this is different from North America: you pay VERY high prices for placing calls, sometimes up to 2$ a minute to call a mobile phone with another network provider... but you get the mobile phone for "free" paying "only 20$ to 100$ a month. It MUST be a deal...
So, if Napster can sell the message well, they can win the battle.
It would not be the first time that the stupidity of the average person wins over common sense.
To be honest, I'd prefer not to do my assignments twice;)
I have developed arithmetic libraries for x86, ARM and PowerPC architectures. It's been a GREAT exercise. Of course I could have implemented it only on a single architecture, but I learned a lot. It was kind of fuzzy to watch my programmes that used to be x86 only run at full speed on my PB. If your professor is intelligent, he/she will give you extra credits, and you have extra experience, which will pay off in the future.
Slashdot Mirror
> Dr. Schatten, who was to have led the organization's
> board of directors, says he is now severing collaboration
> with Dr. Hwang, due to questions over the source of human
> eggs used in a 2004 cloning project, and errors in a 2005
> paper coauthored by the scientists. A 2004 news report
> in the journal Nature said at least one female laboratory
> worker had provided eggs for the project, an allegation
> that Dr. Hwang has denied on several occasions.
Is it just me, or does it look like Schatten didn't have a problem with the forced collection, only starting to sever ties (note the tense there: "is now severing", ie, he hasn't finished?) after problems come up with a paper?
Well, there are a few things you maybe do not know about scientific collaboration projects. When people from different institutions work together, they do not always know all the technical details of the work of each other. There is trust about details which are not of competence of the others. For example I am writing a paper with a colleague from Canada, where I am supposed to implement a specific algorithm he wrote: He does not need to see my code, he need to see the timings. FWIW, I could have asked a "slave" to write it: I did not, but if I did and I did not acknowledge this, this would have been unethical.
Hence, one can assume in good faith that Dr. Schatten did not know the source of the eggs when the paper was written (presumably not later than early 2004). Then the paper was submitted and accepted for publication - scientific journals have a big backlog and the paper was supposed to be in print in 2005. It could have even been that online publication was in 2005 and print in 2006, I did not check this.
If the Nature report was published in 2004, it is simply impossible that the paper was not yet written and that it appears in print now. The paper must have been written before the allegiations have been made.
Now, of course it is entirely possible that he knew what was happening and he did not care about it until the source of the eggs was made known. I have seen worse in the scientific community. Somebody else mentioned prostitutions in this discussion: I have seen entire academic carreers built around a vagina...
Sadly, most people will only see "oh, 1.9 Ghz, it is not even at two" and then read the "3000+" marking on the Athlon CPU and say: shit, the iMac has only 60% of the speed, and still costs more! (and it is not expandable, and it has a one buttone mouse, unless you point out that the mighty mouse is included).
There's also a bit more investment in RSA, there are more fielded products with RSA built-in, and most importantly of all, the patents expired. Did not check the patent situation on Rabin.
I also prefer Rabin over RSA, but both suffer from the same problem: the subexponentiality of solving algorithms.
There are other techiques, ECC is not that complicated, and also codes are not that difficult to implement. I am fond of HECC because it is the main object of my research in crypto at the moment.
But people still stick to technologies that are similar to the old, known ones. For example, just to stick to the discrete logarithm in finite fields, now egregious colleagues are researching algebraic tori a lot. Still, they will suffer from the same problem as RSA or Rabin or the DL in prime fields: subexponentiality of solving the underlying problem will lead to key explosion sooner or later with respect to ECC.
On the other hand Arjen Lenstra made a good analysis that the field element compression techniques will provide a good method for the next few decades. Of course, until there are no new breakthroughs in breaking such schemes (and it seems more likely that people will make a bigger advancement in this area than in the algebraic curve setting).
Let us not forget that ine of the aspects that keeps RSA afloat is the usage of short public exponents. These guarantee that RSA encryption can be done in time quadratic in the key size, whereas ECC and other methods are cubic (RSA decryption is cubic time). You might like this or not, but this is not that bad, even though, as you mentioned, why use an asymmetric system to encipher a large amount of data? You just use it to agree on a key (or to encrypt it) for symmetric method.
Roberto
Exactly, and this because the asymmetric part (RSA) is very slow compared to a symmetric algorithm. So we use the asymmetric part only to perform a key agreement protocol, in other words to agree on a new key to be used in the following symmetric part.
In fact, RSA is starting to age quickly, and there are far better alternatives.
Since there are subexponential algorithms to solve the factoring problem, RSA key sizes will increase a lot in the next years, and will soon be in the thousands of bits.
There are many other choices for asymmetric schemes, and there are groups for which no subexponential attacks in the key or block size are known. These should be used in conjunction with a symmetric scheme such as AES.
Very attractive today are elliptic curves (ECC endorsed also by the NSA, no less [*]) and low genus hyperelliptic curves (HECC). a 140 bit ECC or HECC key offers security equivalent to 1024 bit RSA. The bandwidth advantages are evident, and at this level speed is of the same orged of magnitude, with an advantage of ECC and HECC over RSA.
Arjen Klaas Lenstra wrote a nice contribution in Key Lengths to The Handbook of Information Security. If you cross-reference with the paper he wrote with Erik Verheul on Selecting Key lengths, you will see that 200 bit ECC and HECC should be equivalent to about 4000 bit RSA security, which should be a good estimate for a good security level for the year 2050 - the NSA is proposing to use 571 bit ECC, which provides security equivalent to about 15,000 bit RSA. Now, creating good istances of RSA moduli of that size is lengthy, and at the same time the cryptographic operations become extremely slow. ECC and HECC mantain good speed though.
Multivariate quadratic systems can be used to construct both secure and efficient public key schemes. Their main problem is the key size, which can easily go to several hundreds of kilobytes. But, the attacks are exponential in the block size, which, for the so-called oil-and-vinegar schemes, remain well bounded. They are very fast and are nice for exchanging keys for the symmetric scheme following the asymmetric part.
Lattice-based systems, NTRU (which can be interpreted as a special lattice based system) are also nice alternatives, but it is difficult to construct secure instances. Code-based systems are vey nice, but the main advantages are short signatures, hence their main application is outside the scenario considered here.
[*] The E.U. is endorsing elliptic curves, too. A strategic project, AREHCC, did extensive Advanced Research on Elliptic and Hyperelliptic Curve Cryptography. The web site of the project, now ended, is still up (http://www.arehcc.com/) and there is a bit of interesting material. A book has been just published on the subject, by authors that worked for AREHCC:
R. Avanzi, H. Cohen, C. Doche, G. Frey, T. Lange, K. Nguyen, and F. Vercauteren.
Handbook of Elliptic and Hyperelliptic Curve Cryptography.
Chapman & Hall - CRC Press. 2005.
This is a mammoth book, and for a leaner introduction, with less theory but perhaps better for practitioners one can get
D. Hankerson, A. J. Menezes, and S. A. Vanstone.
Guide to elliptic curve cryptography.
Springer-Verlag, Berlin, 2003.
a very well written introduction. Then there are the two books edited by Blake, Seroussi, and Smart, on ECC. The latter titles however lack a treatment of HECC.
A follow-up project to AREHCC (and NESSIE), called ECRYPT (http://www.ecrypt.eu.org/), has also considerable resources devoted to alternatives to RSA - including ECC, HECC, and all the other alternatives mention
Yes, you are. Your entire argument is based around the idea that without using TCPA, Apple is doomed to have their magnificent operating system ripped off.
Absolutely not. TCPA is ONE way of achieving this, and until now, we have NO evidence whatsoever that it will be used for anything else. There is clear evidence that it will be used to lock the OS to apple hardware.
And, NO I am not tweaking the financials. The bulk of the income still comes from hardware sales.
I did not say that.
How far will you twist and turn to avoid the truth?
I am not twisting anything.
We are discussing here the fact that the presence of this chip can be used to lock the Mac OS on Apple hardware. Apple said this. I also mentioned that this is only one way of achieving this, only one of many different ways.
How about the fact that Apple makes its money from people buying its systems for the lack of hassle?
Please reformulate this sentence in English... why should Apple NOT be allowed to make money from hardware sales?
You mean if Apple just included a simple BIOS check, aunty Doris might purchase a PC clone with Windows XP on, download a hacked version of OSX (with the check removed) from P2P, install it and gloat over Jobs' loss of cash and lack of vision in not implementing a "Trusted computing" infrastructure that would have prevented this.
No, I am not saying this. Anyway, it is clear to me that YOU want to use Apple's fruits of labour without having to support Apple's development. In other words, to me you are angry just because you fear you would not be allowed to be a thief.
There's a different problem. What other uses that infineon DRM chip may have. But you say something quite wrong:
How deluded are you? If you seriously think this is purely to control the distribution of OSX, then Apple zealots are more witless and crazed than I thought. You talk of "profits"... and then ignore the fact that Apple is making most of its money on iTunes and possibly its forthcoming video versions... all of which will be big future users of TCPA once it is established.
Apple currently makes money from hardware, not from iTunes and iPods. Please check the facts. iTunes and iPods are giving them mindshare (at the moment), and I do not have your crystal ball.
And how would an apple machine with a custom chipset any different?
It would be in fact EASIER to modify the (open source) kernel to avoid checking the DRM chip instead of modifying it to work on a different architecture. In both cases the software installation and update mechanism can check if the machine is Apple's or not.
Apple chose the road of less effort to make it difficult to run their OS on other hardware. A road that allows them to use off-the-shelf hardware components more easily, BUT this does not mean that apple hardware will be like "Dells hardware with a dongle attached". There are many different PC brands and luckily only a few have poor build quality as Dells. Look at their use of integrated graphics on final products, or at the extremely poor and faulty laptop screens - 30% of the screens of Dell laptops sold to universities and schools, in my experience, develop white spots within a few months due to poor assembly and quality checking: not the same with Apple.
There's no doubt that the poster you are replying to has missed something. But it seems to me that you also miss something. Apple is a hardware manifacturer. Why should you be able to buy Apple's OS and run it on other hardware, if it is NOT intended for that use? It is not like having an obscure data format for your data, a la Microsoft. It is not giving up the right of accessing your data the way you want. Apple is a hardware manifacturer and they have an OS for their hardware. The OS is there to drive customers to their hardware. Only a part of the development costs comes from OS sales, the bulk of their money comes from hardware.
Now, you would like to have Apple continue to develop their OS but you want to strip them of their main income source by allowing the OS to be installed on non-Apple hardware. It seems to me that the word ``idiot'' can at this point applied also to you, not as an insult, but in the ethimologic meaning: from the greek ``that cannot see'' (i-diot, then the word entered latin, old french, and finally came to english).
You propose to boycott Apple until they agree to give up on income, so that you can use their products in a way they are not envisioned. Sure, bankrupt firms develop their software actively...
Learn programming and start contributing to GNOME development instead, and do not complain, please, if Apple has some features you are not able to implement...
Well, you can do the same with the Dashboard widgets too.
The way of doing it is by activating Dashboards "debug mode", and has been described on countless forums on the net. You can find some information at the following site:
http://www.tigerwiki.com/index.php/Dashboard
If you are really lazy, there is a nice preference pane that activates this for you and more!n e.html
http://www.ego-systems.com/Products/widgetsprefpa
Roberto
AH! You mean remove it from display ;-)
http://virtualearth.msn.com/default.aspx?cp=32.676 439%7C-117.158347&style=h&lvl=17&v=1
http://maps.google.com/maps?ll=32.676147,-117.1575 27&spn=0.005491,0.006289&t=k&hl=en
Roberto
Now watch them on a 1800 Mhz G5.
I watch them without problems on my 1.5 Ghz Alu Powerbook.
We would have: SCHRAEGSTRICHPUNKT! Nachrichten für Sonderlingen! Sachen von Bedeutung! instead. Ayeeeeeeeeeeeeeee!
I am a Mac user and I can tell you: three button mice scare me! If I have to be forced to use multibutton mice, then they should train me IN SMALL STEPS! :-)
Roberto
PS: seriously speaking, I have no need for additional buttons on the trackpad, since the ctrl key is already very close to my fingers, but the additional buttons on the mouse can result handy.
Well, you can have the iPod whell on a trackpad:
http://www-users.kawo2.rwth-aachen.de/~razzfazz/
I am a happy iScroll2 user...
Roberto
Oh no! They are also going to sue Apple for the motion detection sensor in the new powerbooks! They are triggered by gravity, after all!
The discrete logarithm problem (DLP) is the following one: Given a group G generated by an element g, and a second element h of G, find an integer t such that g^t=h.
It is clear where the name discrete logarithm comes from: One could (with some abuse of notation) write that t is the logarithm of h to the base of g. This name is used even when the group G is written additively, i.e. the operation is not a "multiplication" but an "addition" and the "exponentiation" g^t is written as t times g (t.g), hence we speak of "scalar multiplication".
I doubt that they found a successful attack.
In fact, I believe that ECC is a safe method, until quantum computers are built - in which case all methods based on the discrete logarithm problem in abelian groups are killed.
They also proposed ludicrously large parameters in some cases. They know that somebody is going to use them anyway, hence it is better to suggest the same also to US government agencies and industries. Moreover, they bought the rights to some patents from Certicom (I got the news the same day the deal was closed), hence they can charge royalties.
I believe that the european community should use methods which provide the same level security but are not encumbered by those patents. Hyperelliptic curves and trace zero varieties, apart from the scary names :-) are good candidates. With suitably chosen parameters you can attain the same level of security, better performance and live with no legal strings attached.
Say you're using a 200-bit ECC key. Now your 2^100-step brute-force is down to a 2^50-step brute-force. Six years (four Moore doublings) ago, EFF and distributed.net brute-forced another cipher's 56-bit key in under 24 hours.
The 2^100-step brute force is down to 2^50 brute force IF a few bits of the secret key are already known, or obtained by some other means. A good implementation is safe. It is not the first time that partial knowledge (a few bits) of a secret allows for a "cascade" effect, that permits to recover more information in less time. Per se ECMQV is not broken.
...
In response to another question above: ..., p-1} and you do arithmetic modulo p. If you work in the finite field of 2^n elements, the elements of the finite field look like polynomials with degree n with coefficients either 0 or 1. The size of the group that we work with and do the key exchange and everything in has size in the range [((sqrt(q) - 1)^(2g), ((sqrt(q) + 1)^(2g)], so about q^g. That's why hyperelliptic curves are nice: with genus 3 curves, your key size is a third of the length of the key size for elliptic curves.
In crypto we work with these curves over a finite field, which is basically a set of numbers of the size q=p^n, where p, the characteristic, is a prime. We either work with p=2 and n~163 or p = a 163-bit prime and n=1. Elements in the finite field of p elements looks like {0,1,2,
OK, you got some things right, other less so.
With genus 3 curves you DO NOT get key size equal to a third of the length of the key size for elliptic curves. What you get is that the FIELD over which you define the curve and implement the arithmetic gets smaller! To one third. The key has a size equivalent to 3 field elements, hence has the same size as with EC.
If you take into account the attacks by Gaudry, Theriault, Gaudry Thome and Theriault... then already for genus 3 you have to use a slightly bigger key, but 5 to 10% more bits. Not a big deal, and also the field size increases accordingly, so it is a few bits more than one third that of the field used for an elliptic curve.
The advantage is that the operations are performed on smaller fields. On the other hand there are many more of them (the number of finite field operations to operate in the jacobian variety of a hyperelliptic curve of genus g is in practice between O(g^2) and O(g^3), asymptotically closer to the second bound). This means that the multipliers in the arithmetic unit can be made smaller, making the hardware cheaper - or requiring less multiprecision arithmetic in software - but the software implementing the formulae for the oeprations gets more complicated. It is a balance of costs and performance.
The sweet spot for normal security (160-256 "geometric" bits, where the RSA keys could be defined "arithmetic") is still with the elliptic curves: for larger security (as for the 320 bits used by the german "NSA", the BSI, of the 520+ bits adopted by NSA) the sweet spot are genus 2 HEC (see the papers by Avanzi and Wollinger at CHES [Cryptographic Hardware and Embedded Systems] 2004, for a nice divisor doubling formula in even characteristic see the paper by Lange and Stevens at SAC [Selected areas in Cryptography] 2004). I am a very strong proponent of low genus HEC in odd characteristic (fields of the type GF(p) - the integers modulo p in simplified terms) and of Trace Zero Varieties (expecially those constructed from elliptic curves - I have nice implementation results and tricks in even characteristic with my student Emanuele Cesena - his Thesis will be discussed shortly).
Roberto
--
/_/ Faculty of Mathematics and
_/_/ Dr. Roberto Avanzi, Junior Professor
_/ Horst Görtz Institute for IT-Security
/ Ruhr University Bochum
Maybe you read the old VISA report that was written to spread FUD on elliptic curves... The goal was to persuade the banks to keep using integers because the RSA patents were about to expire. EC has some patents on it (most can be easily challenged, because there's just too much prior art anyway) but the ones on RSA in the meantime expired. In fact, the structure of the integers is more transparent and easier to exploit to devise algorithms to solve the main problems on which the cryptosystems are based: factorisation and discrete logarithm problem (DLP) in finite fields (for the non-mathematically literate: integers modulo a prime number and derived structures). Because of this we have subexponential algorithms (the time is subexponential in the bit size of the operands) for solving the DLP in prime fields and factoring integers. But after 20 years of research we still have only exponential time algorithms for elliptic curves and jacobian varieties of hyperelliptic curves of low genus (up to 4).
The structures one should use are:
Elliptic Curves (proposed Koblitz, Miller) over prime or binary fields.
Hyperelliptic curves of genus 2 or 3 (read the papers by Roberto Avanzi at CHES 2004 for implementation details, and the papers by Tanja Lange and Pelzl, Paar for formulae)
Trace Zero Varieties of low dimension (proposed by Gerhard Frey -- read papers by Tanja Lange, Roberto Avanzi, Lange and Avanzi (fortcoming), Avanzi and Cesena, and look also for Silverberg, for theory and implementation details).
For the attacks there is extensive literature. Names to look for for the best attacks on low genus HEC are Gaudry, Theriault (the results are that low genus HEC - this includes EC - are secure).
In a nutshell, EC are as secure as low genus HEC. Read now
Arjen K. Lenstra, Eric R. Verheul: Selecting Cryptographic Key Sizes. J. Cryptology 14(4): 255-293 (2001)
and you shall see that you need about 160 bits for an EC key size to match 1024 bit integers or finite fields. And 256 bits EC provide the security of many thousands bit integers or finite fields. The numbers are not proportional. If 160 bits EC and 1024 bit RSA provide similar speed, RSA and similar systems fall quickly behind in performance. 512 bit EC operations can still be performed in a short time, by 15.000 bit RSA (the equivalent security level) would require many seconds if not minutes to generate a signature on an embedded device!
Also, a weakness in a PROTOCOL is not necessarily a weakness in the algebraic structure the protocol uses. Many protocols are weak, for example the basic Diffie-Hellman key exchange is not as robust as the Diffie-Hellman mathematical problem. But you can make it as robust as the mathematical problem.
To contact Roberto Avanzi, i.e. me, write the name and family name separated by a dot, followed by the AT sign, the letters g m a i l without spacing, a DOT and a COM.
--
_/_/ Dr. Roberto Avanzi, Junior Professor
_/ Horst Görtz Institute for IT-Security
/ Ruhr University Bochum
My God, it's full of... no, wait, not really... oh well...
Well, in Europe they introduced a concept called "interconnection fee" to make, as they put it "competition easier". in fact, every provider has to pay something to the provider of a number which is called from his network. So for every call there are fixed costs, which cannot be then covered by a flat rate. New providers are at a disadvantage, since the customers of the other larger networks can profit from cheaper tariffs for calls placed within the network. A customer of a new provider will pay on average MORE to call, and people calling him/her will also pay more... This allowed the big networks to VERY SLOWLY increase the prices up to a crazy level... This is made worse in Germany by the fact that customers "buy" the cell phone for a small price and then are locked with that provider for 24 months at least.
In Italy this system never got foothold, because, simply, italian customers are smarter than german customers. In italy you buy the cell phone, you pay it full price, you put in it a sim card, and then you phone. The tarifs are always much lower than in Germany - sometimes as low as 25cents (20EUROcents) per minute, even for calling outside the home network.
CRAZY: if I want to call a finnish colleague from germany, and the call is so urgent, and I am out of office, so that I must use the mobile phone, it is much cheaper to do that with my italian prepaid card than with my german contract...
> communicating to people that it's stupid to buy an iPod."
By saying this, he's essentially implying that everyone who owns an iPod is stupid. I don't see any iPod users being persuaded to switch to Napster's service thanks to Mr. Gorog's opinion of them, but considering the size of the iPod's market share, Napster needs to court current iPod/iTMS users, not denigrate them. Besides that, stupid people are his target market-- who else would think paying $15 per month FOREVER (or your music collection disappears) is a good deal?
Apple in the past ruined itself comparing corporate PC users purchasing IBM equipment to lemmings - stupid creatures just following each other to fall from a cliff. That ad was perceived as offensive and was never aired again. So this might be a wrong step from Napster. On the other hand, it is easy to cheat customers, which ARE stupid on the whole. In Germany you have the highest mobile phone tarifs in the world, but people sign new contracts binding them for at least 24 months, and having them paying anywhere between 20$ and 100$ a month, because they get the newest cell phone for a couple of bucks. And this is different from North America: you pay VERY high prices for placing calls, sometimes up to 2$ a minute to call a mobile phone with another network provider... but you get the mobile phone for "free" paying "only 20$ to 100$ a month. It MUST be a deal... So, if Napster can sell the message well, they can win the battle. It would not be the first time that the stupidity of the average person wins over common sense.
I have developed arithmetic libraries for x86, ARM and PowerPC architectures. It's been a GREAT exercise. Of course I could have implemented it only on a single architecture, but I learned a lot. It was kind of fuzzy to watch my programmes that used to be x86 only run at full speed on my PB. If your professor is intelligent, he/she will give you extra credits, and you have extra experience, which will pay off in the future.