February 2009 - cypherpunks-legacy

SHA-3 Round 1: Buffer Overflows
by R.A. Hettinga 23 Feb '09

23 Feb '09

<http://blog.fortify.com/blog/fortify/2009/02/20/SHA-3-Round-1> Off by On A Software Security Blog Search: Friday, 20 February 2009 SHA-3 Round 1: Buffer Overflows + Gartner Magic Quadrant for Static Analysis | Main NIST is currently holding a competition to choose a design for the SHA-3 algorithm (Bruce Schneier has a good description of secure hashing algorithms and why this is important). The reference implementations of a few of the contestants have bugs in them that could cause crashes, performance problems, or security problems if they are used in their current state. Based on our bug reports, some of those bugs have already been fixed. Here's the full story: The main idea behind the competition is to have the cryptographic community weed out the less secure algorithms and choose from the remainder. A couple of us at Fortify (thanks to Doug Held for his help) decided to do our part. We're not hard-core cryptographers, so we decided to take a look at the reference implementations. This competition is to pick an algorithm, but all of the submissions had to include a C implementation, to demonstrate how it works and test the speed, which will be a factor in the final choice. We used Fortify SCA to audit the 42 projects accepted into Round 1. We were impressed with the overall quality of the code, but we did find significant issues in a few projects, including buffer overflows in two of the projects. We have emailed the submission teams with our findings and one team has already corrected their implementation. Confirmed issues: Implementation Buffer Overflow Out-of-bounds Read Memory Leak Null Dereference Blender 1 0 0 0 Crunch 0 0 0 4 FSB 0 0 3 11 MD6 3 2 0 0 Vortex 0 0 1 15 One of the projects with buffer issues was MD6, the implementation provided Professor Ron Rivest and his team. All of the problems came back to the hashval field of the md6_state struct: unsigned char hashval[ (md6_c/2)*(md6_w/8) ]; The buffer size is determined by two constants: #define w md6_w /* # bits in a word (64) */ #define c md6_c /* # words in compression output (16) */ At several points, this buffer is read or written to using a different bound: if (z==1) /* save final chaining value in st->hashval */ { memcpy( st->hashval, C, md6_c*(w/8) ); return MD6_SUCCESS; } Further analysis showed that ANSI standard layout rules would make incorrect behavior unlikely, but other compilers may have allowed it to be exploited. The MD6 team has doubled the size of the vulnerable buffer, which eliminated the risk. In this case, Fortify SCA found an issue that would have been difficult to catch otherwise. The other buffer overflow was found in the Blender implementation, from Dr. Colin Bradbury. This issue was a classic typo: DataLength sourceDataLength2[3]; // high order parts of data length ... if (ss.sourceDataLength < (bcount | databitlen)) // overflow if (++ss.sourceDataLength2[0] == 0) // increment higher order count if (++ss.sourceDataLength2[1] == 0) // and the next higher order ++ss.sourceDataLength2[3]; // and the next one, etc. The developer simply mistyped, using 3 instead of 2 for the array access. This issue was probably not caught because it would not be exposed without a very large input. The other issues we found were memory leaks and null dereferences from memory allocation. This just emphasizes what we already knew about C, even the most careful, security conscious developer messes up memory management. Some of you are saying, so what? These are reference implementations and this is only Round 1. There are a few problems with that thought. Reference implementations don't disappear, they serve as a starting point for future implementations or are used directly. A bug in the RSA reference implementation was responsible for vulnerabilities in OpenSSL and two seperate SSH implementations. They can also be used to design hardware implementations, using buffer sizes to decide how much silicon should be used. The other consideration is speed, which will be a factor in the choice of algorithm. The fix for the MD6 buffer issues was to double the size of a buffer, which could degrade the performance. On the other hand, memory leaks could slow an implementation. A correct implementation is an accurate implementation. We will put out a more detailed report on all the results soon. Technorati Tags: sha-3 buffer overflow Posted by jforsythe at 5:41 PM in crypto

4 3

No pain and everything to gain - A perfect body
by Mack Bryant 23 Feb '09

23 Feb '09

Try risk free Acai berries and lose those pounds   Click everyone

1 0

$59.95 Viagra 50mg x 10 pills buy now
by Donnell Jenkins 23 Feb '09

23 Feb '09

$159.95 buy now Viagra (Sildenafil) 100mg x 90 pills http://specialmusicoffer.com.es

1 0

Now you will never be mad at your male friend again.
by Alonzo Medeiros 23 Feb '09

23 Feb '09

Women start laughing when you pull down your pants? Stop it!   Ring the bell now

1 0

Why Oprah Winfrey Endorses Acai Berry For WieghtLoss hxkqju uk
by Hilde Marline 23 Feb '09

23 Feb '09

When celebrities endorse a product, people flock to buy it. The Queen of Daytime Gab, Oprah Winfrey, recently raved about a new supplement on her show. After her own personal struggles with weight, her suggestion for a wieghtLoss supplement got everyone excited. Oprah endorsed Acai berry as a wonderful wieghtLoss supplement that is all natural and safe for the general public. Oprah found out about Acai berries from Dr. Nicolas Perricone. He appeared on her show to discuss the top ten "superfoods" to help people get healthy. His number one "superfood" was MonaVie, which is derived from Acai berry. Dr. Perricone has done extensive research on Acai berry, which originated in the Amazon rainforest. He listed acai's amazing properties in his book, "The Perricone Promise", explaining the perks of using this miracle food. Fresh acai berries are the best choice for health benefits, but you can also get the fruit in juice, powder, or extracts. Many people enjoy drinking a cup of Acai berry tea. It's fruity flavor leaves a soothing sensation on the stomach. Acai berries have multiple benefits, but the most popular is increased wieghtLoss. Acai berries speed up the metabolism and help food travel through the body at a faster rate. This prevents fat from building up so you can loseWieght quickly. People lose an average of 8 to 25 pounds each month on Acai berry supplements. Acai berries are so rich in important vitamins and minerals that they can replace several high calorie foods. The acai berry has as much protein as an egg and 30 times as much anthocyanin as red wine. Oprah saw tremendous potential in this little "superfood" and it wasn't long before America jumped on board to give acai berries a try. People were instantly hooked to the high energy levels and rapid wieghtLoss. Competition heated up between companies and now you can easily sign up for Free Acai Berry Supplements. To try a free bottle sample of Acai Berry http://sox.difxdfew.cn and follow up on one of my client's amazing wieghtLoss story, just visit below site and see why Acai Berry has changed the lives of millions! http://snln.difxdfew.cn

1 0

Re: SHA-3 Round 1: Buffer Overflows
by Ian G 23 Feb '09

23 Feb '09

On 23/2/09 23:41, Jerry Leichter wrote: > On Feb 23, 2009, at 3:44 PM, Ian G wrote: >> However I think it is not really efficient at this stage to insist on >> secure programming for submission implementations. For the simple >> reason that there are 42 submissions, and 41 of those will be thrown >> away, more or less. There isn't much point in making the 41 secure; >> better off to save the energy until "the one" is found. Then >> concentrate the energy, no? > I disagree here. If there's a reason to submit running implementations > at all - and one can certainly argue that there isn't, at least in early > phases where we are nominally looking at the algorithms, not particular > bindings to code - then those implementations should be of reasonable > quality. How can that be? If you don't know the reason to provide the C, how can you argue that it has to be of a "reasonable quality" ? What's the security / business / purpose / anything model here? > In this day and age, most of these errors - buffer overflows, > null dereferences, out-of-bound reads - simply cannot be part of code of > reasonable quality. I can live with memory leaks - at least they don't > affect correctness, and in non-parallel algorithms (which these > presumably are) they can generally be found and fixed later. But the > others represent some fundamental problems with the translation of the > algorithm pseudo-code into actual C code. So we have two presentations > of the "algorithm", one in pseudo-code, one in C - which are different. > Which is "right"? Again, if only the pseudo-code has to be "right", Well, this is all good and fine if there is a purpose to this code that needs the above. But this is a *competition for an algorithm.* So far, quality of code is not anything more than a distraction; if I recall the last time, the first AES contender was broken out before the end of its presentation at the first conference! > why > is the C there at all? OK, I admit here, I do not know why there is C at all. Thinking back to my Java/AES experiences, I don't recall why there was code, either. I can only hypothesise that it increased exposure, and gave a little bit more experience, also a sense of "proving it is at least minimally practical." (Luckily, Java makes writing "reasonable quality" code easy, so I didn't have to answer it. I recall that Rijndael team was very lucky to have good solid C help though.) > The fact of the matter is that code, once it's > public, takes on a life of its own. People will go look at the reference > implementations for guidance - and in some cases they will find these > initial reference implementations. Further, if the AES competition is > any guide, some of the algorithms proposed but no selected will survive > and see use for multiple reasons, most probably bad, some perhaps > reasonable. The initial reference implementations, in that case, may be > all that ever gets published. This is their lookout. Frankly, this is taking code and placing it on a pedestal. If these "people" go download stuff from the net and build it into security implementations, well, they need to do a little "risk management" about what stuff found on the net is all about. > It's also been pointed out that performance of actual implementations > will form part of the selection criteria. I can always make my code > faster if I don't have to make it right! Based on this data, we can't > use the current crop of C code for *any* comparisons - not even to > estimate the sizes of temporary data needed for an implementation (since > the cause of one of the memory reference errors is a buffer half the > size it needs to be). OK, here I can comment: I would predict most of the performance discussions are likely to be based on hardware issues. They will be talking about gate counts and so forth, and if they get "soft" they'll be talking about instruction cycles and register sizes. The C code won't really help there, and the Java will likely be totally ignored. (YMMV, of course.) > Putting examples of incorrect code out there for people to look at is > never a good idea! We have way too much of it already. Then a little more won't hurt :) Let them have their fun; once we get to the last round (5 algorithms?) then make it better. iang

1 0

Viagra Super Active Sildenafil 100mg Only $1.99 per pill + Christmas Gift ioh
by Elsie Conner 23 Feb '09

23 Feb '09

Dear cypherpunks(a)jfet.org l http://internetstorecard.com.es Cheap prices for all meds. http://internetstorecard.com.es

1 0

Re: Shamir secret sharing and information theoretic security
by R.A. Hettinga 23 Feb '09

23 Feb '09

Begin forwarded message: > From: Jerry Leichter <leichter(a)lrw.com> > Date: February 22, 2009 2:37:13 PM EST > To: R.A.Hettinga <rah(a)shipwright.com> > Cc: Cryptography <cryptography(a)metzdowd.com> > Subject: Re: Shamir secret sharing and information theoretic security > > On Feb 17, 2009, at 6:03 PM, R.A. Hettinga wrote: > >> Begin forwarded message: >> >> From: Sarad AV <jtrjtrjtr2001(a)yahoo.com> >> Date: February 17, 2009 9:51:09 AM EST >> To: cypherpunks(a)al-qaeda.net >> Subject: Shamir secret sharing and information theoretic security >> >> hi, >> >> >> I was going through the wikipedia example of shamir secret sharing >> which says it is information theoretically secure. >> >> http://en.wikipedia.org/wiki/Shamir%27s_Secret_Sharing >> >> In the example in that url, they have a polynomial >> f(x) = 1234 + 166.x + 94.x^2 >> >> they construct 6 points from the polynomial >> (1,1494);(2,1942);(3,2578);(4,3402);(5,4414);(6,5615) >> >> the secret here is S=1234. The threshold k=3 and the number of >> participants n=6. >> >> If say, first two users collude then >> 1494 = S + c1 .1 + c2.1 >> 1942 = S + c1 .2 + c2.2 >> >> clearly, one can start making inferences about the sizes of the >> unknown co-efficients c1 and c2 and S. >> >> >> However, it is said in the URL above that Shamir secret is >> information theoretically secure > It is. Knowing some of the coefficients, or some constraints on > some of the coefficients, is just dual to knowing some of the > points. Neither affects the security of the system, because the > coefficients *aren't secrets* any more than the values of f() at > particular points are. They are *shares* of secrets, and the > security claim is that without enough shares, you have no > information about the remaining shares. > > The argument for information-theoretic security is straightforward: > An n'th degree polynomial is uniquely specified if you know its > value at n+1 points - or, dually, if you know n+1 coefficients. On > the other hand, *any* set of n+1 points (equivalently, any set of n > +1 coefficients) corresponds to a polynomial. Taking a simple > approach where the secret is the value of the polynomial at 0, given > v_1, v_2, ..., v_n and *any* value v, there is a (unique) polynomial > of degree at most n with p(0) = v and p(i) = v_i for i from 1 to n. > Dually, the value p(0) is exactly the constant term in the > polynomial. Given any fixed set of values c_1, c_2, ..., c_n, and > any other value c there is obviously a polynomial p(x) = Sum_{0 to n} > (c_i x^i), where c_0 = c, and indeed p(0) = c. > > Or ... in terms of your problem: Even if I give you, not just a > pair of linear equations in c1, c2, and S, but the actual values c1 > and c2 - the constant term (the secret) can still be anything at all. > > The description above is nominally for polynomials over the reals. > It works equally for polynomials over any field - like the integers > mod some prime, for example. For a finite field, there is an > obvious interpretation of probability (the uniform probability > distribution), and given that, "no information" can be interpreted > in terms of the difference between your a priori and a posterio > estimates of the probability that p(0) takes on any particular > value, the values of p(1), ..., p(n) (and that differences is > exactly 0). Because there can be no uniform probability > distribution over all the reals, you can't state things in quite the > same way, and "information theoretic security" is a bit of a vague > notion. Then again, no one does computations over the reals. FP > values - say, IEEE single precision - aren't a field and there are > undoubtedly big biases if you try to use Shamir's technique there. > (It should work over infinite-precision rationals.) > > -- Jerry > > >> >> >> in the url below they say >> http://en.wikipedia.org/wiki/Information_theoretic_security >> "Secret sharing schemes such as Shamir's are information >> theoretically secure (and in fact perfectly secure) in that less >> than the requisite number of shares of the secret provide no >> information about the secret." >> >> how can that be true? we already are able to make inferences. >> >> Moreover say that, we have 3 planes intersecting at a single point >> in euclidean space, where each plane is a secret share(Blakely's >> scheme). With 2 plane equations, we cannot find the point of >> intersection but we can certainly narrow down to the line where the >> planes intersect. There is information loss about the secret. >> >> >> from this it appears that Shamir's secret sharing scheme leaks >> information from its shares but why is it then considered >> information theoretically secure? >> >> They do appear to leak information as similar to k-threshold >> schemes using chinese remainder theorem. >> >> what am i missing? >> >> Thanks, >> Sarad. >> >> >> --------------------------------------------------------------------- >> The Cryptography Mailing List >> Unsubscribe by sending "unsubscribe cryptography" to majordomo(a)metzdowd.com > > Begin forwarded message: > From: sbg(a)acw.com > Date: February 23, 2009 1:05:47 PM EST > To: "Jerry Leichter" <leichter(a)lrw.com> > Cc: "R.A. Hettinga" <rah(a)shipwright.com>, "Cryptography" <cryptography(a)metzdowd.com > > > Subject: Re: Shamir secret sharing and information theoretic security > > Is it possible that the amount of information that the knowledge of a > sub-threshold number of Shamir fragments leaks in finite precision > setting > depends on the finite precision implementation? > > For example, if you know 2 of a 3 of 5 splitting and you also know > that > the finite precision setting in which the fragments will be used is > IEEE > 32-bit floating point or GNU bignum can you narrow down the search > for the > key relative to knowing no fragments and nothing about the finite > precision implementation? > > > Begin forwarded message: > From: Jerry Leichter <leichter(a)lrw.com> > Date: February 23, 2009 2:03:01 PM EST > To: sbg(a)acw.com > Cc: "R.A. Hettinga" <rah(a)shipwright.com>, "Cryptography" <cryptography(a)metzdowd.com > > > Subject: Re: Shamir secret sharing and information theoretic security > > On Feb 23, 2009, at 1:05 PM, sbg(a)acw.com wrote: > >> Is it possible that the amount of information that the knowledge of a >> sub-threshold number of Shamir fragments leaks in finite precision >> setting >> depends on the finite precision implementation? >> >> For example, if you know 2 of a 3 of 5 splitting and you also know >> that >> the finite precision setting in which the fragments will be used is >> IEEE >> 32-bit floating point or GNU bignum can you narrow down the search >> for the >> key relative to knowing no fragments and nothing about the finite >> precision implementation? > I've never seen any work done in this direction. When you consider > exact values, FP arithmetic is very messy and has almost no nice > mathematical properties. (It's nice in a model where all you care > about is relative error - which is actually a rather unnatural > model!) As a result, I think it's unlikely you can come up with any > general theory here. But you can probably come up with examples > showing that there's a problem. It's usually easiest to work with a > simpler form of FP math - e.g., assume 4 decimal digits and a 1- > digit decimal exponent. Consider just quadratics, which we can > write as > p(x) = (x - r1)*(x - r2). If r1*r2 overflows in a particular FP > system, you can't write down the value of the constant coefficient - > hence, you can't write down the value p(0). Yet p(1) and p(2) might > have values you *can* write down. I'm not sure how you leverage > this to produce a bias, but it certainly shows that FP arithmetic > just plain doesn't have the right properties to support the > reasoning behind Shamir secret sharing.... > > -- Jerry

1 0

Save On Pills - AMERICA's #1 family Pharmacy. Discount Pills, Vitamins and More nvh is
by Jimmie Millicent 23 Feb '09

23 Feb '09

ViagraU, CialisU, ViagraU Professional, CialisU Professional, ViagraU_SoftTabs, CialisU_SoftTabs, PenisGrowthPill, LevitraU, LevitraU Professional, Female ViagraU, PenisGrowthPatch and other drugs with wholesale prices. You wont find better prices anywhere else! http://cody.ibdnhfge.cn ViagraU(50mg): 10 pills x 50mg $37.00 30 pills x 50mg $69.00 60 pills x 50mg $124.00 90 pills x 50mg $179.00 120 pills x 50mg $213.00 180 pills x 50mg $275.00 270 pills x 50mg $396.00 360 pills x 50mg $509.00 ViagraU(100mg): 10 pills x 100mg $39.00 30 pills x 100mg $97.93 60 pills x 100mg $154.00 90 pills x 100mg $192.00 120 pills x 100mg $229.00 180 pills x 100mg $298.00 270 pills x 100mg $429.00 360 pills x 100mg $549.00 CialisU(10mg): 10 pills x 10mg $42.49 20 pills x 10mg $74.49 30 pills x 10mg $99.49 60 pills x 10mg $179.49 90 pills x 10mg $229.49 120 pills x 10mg $299.49 180 pills x 10mg $399.49 CialisU(20mg): 10 pills x 20mg $48.00 20 pills x 20mg $85.00 30 pills x 20mg $115.00 60 pills x 20mg $199.00 90 pills x 20mg $259.00 120 pills x 20mg $319.00 180 pills x 20mg $439.00 .much more meds on our site Please click below links and check out our offer. http://czr.ibdnhfge.cn

1 0

$159.95 Price for 100mg x 90 pills
by Ellen Wilcox 23 Feb '09

23 Feb '09

$99.95 buy now Viagra (Sildenafil) 100mg x 30 pills http://specialoffermail.com.es

1 0