Re: Password hashing
I forgot to add the links... http://people.redhat.com/drepper/sha-crypt.html http://people.redhat.com/drepper/SHA-crypt.txt On Oct 11, 2007, at 10:19 PM, james hughes wrote: A proposal for a new password hashing based on SHA-256 or SHA-512 has been proposed by RedHat but to my knowledge has not had any rigorous analysis. The motivation for this is to replace MD-5 based password hashing at banks where MD-5 is on the list of do not use algorithms. I would prefer not to have the discussion MD-5 is good enough for this algorithm since it is not an argument that the customers requesting these changes are going to accept. Jim
Avoiding certicom patents.
-- Avoiding certicom patents. The two patents that are actually useful are point compression and ECMQV Bodo Moeller, quoted by Bernstein, points out that one can do point compression following the method of page 171 of the Harper-Menezes-Vanstone paper Public-key cryptosystems with very small key lengths at Eurocrypt '92, published more than a year before the filing of the point compression patent. :: The key length can be shortened to n+1 bits as :: follows. Observe first that the change of :: variables (x,y) - (x,xz) transforms equation :: :: y^2 + x*y = x^3 + a*x^2 + b, (1) :: :: to :: :: z^2 + z = x + a + b*x^(-2), (3) :: :: Given the x-coordinate of a point P = (x,y), :: we can compute the right hand side of (3). :: Then (3) has precisely 2 solutions, namely z' :: and z'+1, and these solutions can be easily :: found. We can then select the correct solution :: z (and hence reconstruct y as y = xz) if we :: know the least significant bit of z. Thus to :: transmit P it is sufficient to transmit x and :: the least significant bit of y/x. I am not a lawyer, but if one follows the method as given in the paper, and place direct quotes from the paper in the source code comments and product documentation, that should cover one's ass. What ECMQV does is get forward secrecy *and* authentication without additional cost. If, however, we don't need the point compression patent, neither do we need ECMQV. Let capital letters represent elliptic curve points, lower case letters represent integers modulo the order of the generator. Multiplication of an elliptic curve point by an integer to give another elliptic curve point takes polynomial time, division by an integer takes exponential time, takes time 2^(n^2) where n is the bit size of the field. Simpe DH is as follows: Bob has a secret key b, the integer b, and a well known public key B = b*G, where G is the generator. Carol has a secret key c, the integer c, and a well known public key C = c*G, where G is the generator. Bob constructs the shared secret b*C, Carol constructs the shared secret c*B, b*C=c*B This, however, means they use the same secret each time, which can cause problems. Best to use a secret that randomly changes from time to time. So to fix this: Bob generates a random and frequently changing secret number x, and transmits the point compressed value of X, X=x*G to Carol. Carol generates a random and frequently changing secret number y, and and transmits the point compressed value of Y, Y=y*G to Bob. Bob computes (x+b)*(Y+C), Carol computes (c+y)*(X+B). (x+b)*(Y+C) =(c+y)*(X+B) Now if we were transmitting uncompressed points, there would be some attacks which ECMQV prevents, but since we are transmitting compressed points, these attacks cease to work. I repeat, I am not a lawyer, but then neither are the judge or jury mathematicians. If you simply don't have the additional steps listed in ECMQV, how are they going to justify the claim that it somehow really is ECMQV? Note that that point compression avoids the attacks that motivate ECMQV has not been examined in the literature, nor have patent lawyers looked at any of the information I present here. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG Hby8ToP7gt/aBQ1wfI7BDP13fj4dqb/RwBUcQtKe 4kJnBa/Brr+PMEJFoEXvPbwbP2fcEYkPJo0Co59YI - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: 307 digit number factored
A 307 digit number is 1024 bits, near enough. 1024 bits was scheduled to fail in 2013. It has failed early, due to modest advances in factorization. Thus past comparisons of the strength of encryption key sizes are no longer entirely accurate. Further, they never were that accurate to start with - one needs actual run times for breaks run on the same machine. None of the past comparisons have started from such concrete data. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Password hashing
A proposal for a new password hashing based on SHA-256 or SHA-512 has been proposed by RedHat but to my knowledge has not had any rigorous analysis. The motivation for this is to replace MD-5 based password hashing at banks where MD-5 is on the list of do not use algorithms. I would prefer not to have the discussion MD-5 is good enough for this algorithm since it is not an argument that the customers requesting these changes are going to accept. Jim - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: 307 digit number factored
[EMAIL PROTECTED] wrote: AFAIK, the only advantage of ECC is that the keys are shorter. The disadvantage is that it isn't as well studied. Nate Lawson wrote: Again, this is well covered. The reason is the fundamental difference in the performance of the best-known attacks (GNFS vs. Pollard's rho). http://www.vaf.sk/download/keysize.pdf At the timpe that http://www.vaf.sk/download/keysize.pdf was published, 1024 bit asymmetric encryption over integers was comparable in strength to 80 bit symmetric encryption, and elliptic curve encryption over a 160 bit fields. At that time integers based asymmetric encryption took about four times as long to compute as the comparable strength elliptic curve asymmetric encryption. Since then, integer encryption has weakened further relative to elliptic curve encryption, due to advances in factorization and the discrete log problem, increasing the advantage of elliptic curves. With widespread failure to use encryption due to the computational costs a factor of more than four is not to be sneezed at. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: 307 digit number factored
-- [EMAIL PROTECTED] wrote: AFAIK, the only advantage of ECC is that the keys are shorter. The disadvantage is that it isn't as well studied. On past performance, elliptic curves are safer than integers. From time to time, integer based asymmetric encryption is abruptly and surprisingly weakened by advances in discrete log algorithms. This is just not happening with elliptic curves. The cost of computing power is going down faster than the cost of communication. The size of sufficiently safe asymmetric encryption based on integers is growing considerably faster than the size of sufficiently safe asymmetric encryption based on elliptic curves. Thus the advantage of elliptic curve encryption continually increases, will become overwhelming in the near future - and a large part of that continually increasing advantage comes from unpredictable improvements in factoring and discrete log over the integers. My intuition is that because elliptic curves are considerably less orderly than the integers, there is less scope for discovering fast discrete log methods. We are continually discovering improvements to finding discrete logs over the integers. It has been a long time since any such has been discovered for elliptic curves, long enough to give a plausible hope that no further such will ever be discovered. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG ibAQXQ+Yoy5neOvRwKJwdxVLDGSPwTxKobkv566h 4khPsLmyqlil/F6sx2n1q9mtb65W8RMcWyqxregOo - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Trillian Secure IM
| Which is by the way exactly the case with SecureIM. How | hard is it to brute-force 128-bit DH ? My guesstimate | is it's an order of minutes or even seconds, depending | on CPU resources. Sun's Secure NFS product from the 1980s had 192-bit Diffie-Hellman, and a comment in one of the O'Reilly NFS books says that However, by 1990, advances in RISC processors produced workstation machines that could, by brute force, derive the private key from any public key in under a day. but that in 1987 there were still a lot of Motorola 68010 machines that took several minutes to generate keys so they didn't want it longer. I'm guessing that a 1990 RISC machine was around 50 MIPS, so it's maybe 1/100 the speed of a modern single-core CPU. 128-bit DH sounds like as good a decision as using 40-bit RC4 keys would be today. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Yahoo! follies.
Today's hall of shame entrant is, oddly, not a bank, but Yahoo!. Yahoo! Wallet. Because shopping is more fun than typing. o Store all your credit card, shipping and billing information. (Never type it in again!) o Easy check out at 1000s of merchants. o Use Wallet for purchases all around Yahoo! o Safe, Simple, and Secure. Sign up now. -- http://wallet.yahoo.com/ Earlier today, I discovered that someone had stolen my credit card number. These days, it is important to test out the credit card you've stolen somehow before using it for a big purchase. If you have physical possession of the card, the usual means these days is to do a small charge at a gas station. If you don't have physical possession, you need other means. Apparently, the means by which my particular thieves tested out their new acquisition was with the use of Yahoo!'s Yahoo! Wallet facility, and this is apparently a spreading practice. It is with no small irony that Yahoo! Wallet advertises itself as Safe, Simple and Secure. My issuing bank shut off my card after a charge was made with Yahoo! Wallet. The charge was for $1. There was also a much larger suspicious charge, but the test was apparently via Yahoo! Wallet. I suggested to the guy at my issuing bank's fraud department that we call up the Yahoo! Wallet people up, just to make sure the attempted $1 charge (which Yahoo! makes and afterwards reverses to test the card numbers they are given -- kind of them to automate that step for fraudsters) wasn't somehow triggered by something I had done without realizing it, and to see if we could find out anything about who had made the charge. The fellow at my issuing bank's fraud department thought it would do no good, but he called up Yahoo! with me on the phone anyway, with a sound of resignation in his voice as he did it. I later learned why he sounded so unenthusiastic. He'd been down this route before. Yahoo! Wallet's customer service is run out of the Philippines, and has the same keen sense of organization, training and fraud prevention that one might find among kindergarteners with lifelong iodine deficiency. We were quickly informed of about four or five things by the customer service representative, all of them mutually contradictory and some of them frankly incomprehensible because of the mangled grammar. However, one thing he did say consistently was that he could not release information on the account that had been created with my credit card -- not even if I, the lawful owner of the account, requested it, and not even if the issuing bank requested it. They would only release such information if they got a legal order to do so, although there is no right to financial privacy in US law on the part of people using another person's account fraudulently. It was explained to us, by the fairly confused and not entirely well trained representative, that he could only release the information to us if the credit card number that had been entered in was incorrect and had not been successfully charged -- a policy that made just about as close to no sense as one can imagine. I asked to speak to a supervisor, and my bank's rep and I were transferred after some time to an equally clueless individual. So let me get this straight. You are not allowed to give the fraud investigation department at the issuing bank information about a fraudulent account opened using a credit card from the issuing bank even if both the issuing bank and the legitimate owner of the card request it. Yes sir. But if the credit card number had been incorrect and we had somehow gave it you, you could give us the account information. Yes sir. You do realize that not only does this make absolutely no sense, it also makes ``Yahoo! Wallet'' the ideal way for people to check cards before committing credit card fraud, right? And the rep went on to explain that wasn't their intent -- but their intent clearly doesn't matter, only the results matter. After the Yahoo! people (well, not really Yahoo! but almost certainly the low bid contractor) got off the phone with us, the guy from my bank noted to me that he had suspected the whole thing would be a waste of time, as it was. I asked him how it was that Yahoo! could operate with policies like this without getting their merchant account pulled, and he opined that he didn't know, but he was no more pleased with it than me. So, let me note to all of you out there trying to commit financial fraud, that Yahoo! Wallet is an especially Safe, Simple and Secure way for you to verify that an account you have stolen is good. It is especially Safe and Secure because Yahoo! will do their utmost to block legitimate investigation into fraudulent use of credit cards. One wonders what exactly the people who came up with these policies were thinking, since doubtless this costs them money and will eventually result in serious trouble for them, but my experience in such matters is that,
Quantum Crytography to be used for Swiss elections
No comment from me on the appropriateness. From Computerworld. -- Jerry Quantum cryptography to secure ballots in Swiss election Ellen Messmer October 11, 2007 (Network World) Swiss officials are using quantum cryptography technology to protect voting ballots cast in the Geneva region of Switzerland during parliamentary elections to be held Oct. 21, marking the first time this type of advanced encryption will be used for election protection purposes. Still considered an area of advanced research, quantum cryptography uses photons to carry encryption keys to secure communications over fiber-optic lines and can automatically detect if anyone is trying to eavesdrop on a communications stream. For the Swiss ballot-collection process, the quantum cryptography system made by id Quantique will be used to secure the link between the central ballot-counting station in downtown Geneva and a government data center in the suburbs. We would like to provide optimal security conditions for the work of counting the ballots, said Robert Hensler, the Geneva State Chancellor, in a statement issued today. In this context, the value added by quantum cryptography concerns not so much protection from outside attempts to interfere as the ability to verify that the data have not been corrupted in transit between entry and storage. The use of quantum cryptography in the voting process will showcase technology developed in Switzerland. The firm id Quantique, based in Carouge, grew out of research done at the University of Geneva by Professor Nicolas Gisin and his team back in the mid-1990s. According to id Quantique's CEO Gregoire Ribordy, the firm's Cerberis product, developed in collaboration with Australian company Senetas, will be used for the point-to-point encryption of ballot information sent over a telecommunications line from the central ballot-counting station to the government data center. Ribordy said the Swiss canton of Geneva -- there are 26 cantons throughout all Switzerland -- has about 200,000 registered voters who will either go to the polls on Oct. 21 and cast their vote, or vote by mail. The votes cast by mail are all collected in the days before the election and all brought to the central counting station on Oct. 21, Ribordy said. Once the election is closed -- at noon on Sunday, Oct. 21 -- the sealed ballot boxes of all the polling stations are brought to the central counting station, where they are opened and where the votes are mixed with the mail votes. Counting them is then manually done at the central counting station. People counting the votes at this central station use computers to transfer the counts to the data center of the canton of Geneva, Ribordy explained. He said the quantum cryptography system is ready to be put into action. Ribordy doesn't think the high-speed link has been encrypted by any means in the past, but he added that the IT department of the Swiss government is not sharing a lot of information on certain details for security reasons. The use of quantum cryptography in the Swiss election marks the start of the SwissQuantum project managed by Professor Gisin, with support from the National Center of Competence in Quantum Photonics Research in Switzerland. Protection of the federal elections is of historical importance in the sense that, after several years of development and experimentation, this will be the first use of the 1GHz quantum encrypter, which is transparent for the user, and an ordinary fiber-optic line to send data endowed with relevance and purpose, said Professor Gisin in a prepared statement. So this occasion marks quantum technology's real debut. The SwissQuantum project aims to set up a pilot communications network throughout Geneva. Supporters compare it with that of the first Internet links in the United States in the 1970s. The Swiss are also expected to showcase the quantum cryptography project during the ITU Telecom World event being held in Geneva this week. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Password hashing
On Thu, 11 Oct 2007 22:19:18 -0700 james hughes [EMAIL PROTECTED] wrote: A proposal for a new password hashing based on SHA-256 or SHA-512 has been proposed by RedHat but to my knowledge has not had any rigorous analysis. The motivation for this is to replace MD-5 based password hashing at banks where MD-5 is on the list of do not use algorithms. I would prefer not to have the discussion MD-5 is good enough for this algorithm since it is not an argument that the customers requesting these changes are going to accept. NetBSD uses iterated HMAC-SHA1, where the password is the key and the salt is the initial plaintext. (This is my design but not my implementation.) --Steve Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Password hashing
I would have thought PBKDF2 would be the obvious, standardized (PKCS #5 / RFC 2898) and designed for purpose method to derive a key from a password. PBKDF2 would typically be based on HMAC-SHA1. Should be straight-forward to use PBKDF2 with HMAC-SHA-256 instead for larger key sizes, or for avoidance of SHA1 since the partial attacks on it. Adam On Thu, Oct 11, 2007 at 10:19:18PM -0700, james hughes wrote: A proposal for a new password hashing based on SHA-256 or SHA-512 has been proposed by RedHat but to my knowledge has not had any rigorous analysis. The motivation for this is to replace MD-5 based password hashing at banks where MD-5 is on the list of do not use algorithms. I would prefer not to have the discussion MD-5 is good enough for this algorithm since it is not an argument that the customers requesting these changes are going to accept. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
