×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Security Review Summary of NIST SHA-3 Round 1

timothy posted more than 5 years ago | from the works-in-progress dept.

Encryption 146

FormOfActionBanana writes "The security firm Fortify Software has undertaken an automated code review of the NIST SHA-3 round 1 contestants (previously Slashdotted) reference implementations. After a followup audit, the team is now reporting summary results. According to the blog entry, 'This just emphasizes what we already knew about C, even the most careful, security conscious developer messes up memory management.' Of particular interest, Professor Ron Rivest's (the "R" in RSA) MD6 team has already corrected a buffer overflow pointed out by the Fortify review. Bruce Schneier's Skein, also previously Slashdotted, came through defect-free."

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

146 comments

SHA-3 Is Cracked. (-1, Troll)

Anonymous Coward | more than 5 years ago | (#26950475)

Otherwise the NSA wouldn't have let it get this far.

Re:SHA-3 Is Cracked. (1, Funny)

Anonymous Coward | more than 5 years ago | (#26950537)

If you step into my heap one more time with your fucking malloc, I'm going to derefernce your null pointer bitch!

-Christian Bale

Re:SHA-3 Is Cracked. (1, Troll)

gavron (1300111) | more than 5 years ago | (#26950639)

Your null pointer bitch derefernced[sic] herself and crashed, or I'll take out your fucking lights. How would you like that?

Re:SHA-3 Is Cracked. (0)

Anonymous Coward | more than 5 years ago | (#26950855)

Oooooh good *odd pause* for you!

Re:SHA-3 Is Cracked. (0)

Anonymous Coward | more than 5 years ago | (#26954387)

If you step into my heap one more time with your fucking malloc, I'm going to derefernce(sic) your null pointer bitch!
-Christian Bale

Really? What film is this from?

What do you call a penis up your ass? ASS-PENIS!! (-1, Troll)

Anonymous Coward | more than 5 years ago | (#26950487)

Most niggers in Africa don't know what SHA-3 is. Therefore, SHA-3 is RACIST!

nigger nigger nigger

ANSI C (4, Insightful)

chill (34294) | more than 5 years ago | (#26950515)

That is what they get for mandating the code be in ANSI C. How about allowing reference implementation in SPARK, ADA or something else using design-by-contract. After all, isn't something as critical as a international standard for a hash function the type of software d-b-c was meant for?

Re:ANSI C (3, Interesting)

RichardJenkins (1362463) | more than 5 years ago | (#26950549)

Why do they even have a reference implementation for a hash function in a programming language? Wouldn't just defining the function mathematically be less error prone and just as effective?

Re:ANSI C (1, Informative)

Anonymous Coward | more than 5 years ago | (#26950625)

1. Because we, rank and file developers, have to use it afterward (and some of us write in C or C-derived languages, like oh, I don't know, pretty much all applications on your desktop?)

2. Because it is impossible to compare performance of cryptographic algorithms if they are not written in a same language (preferably directly convertable to machine code)

Re:ANSI C (1, Insightful)

Anonymous Coward | more than 5 years ago | (#26950627)

Ummmm... because it wouldn't be a reference implementation if it wasn't actually implemented?

Re:ANSI C (0)

Anonymous Coward | more than 5 years ago | (#26950637)

Why do they even have a reference implementation for a hash function in a programming language?

So computers can run it (duh). It wouldn't be much of an implementation otherwise.

Wouldn't just defining the function mathematically be less error prone and just as effective?

Only if you have a way to transform pure math into executable machine code. If you did, that would be a ... wait for it ... programming language!

Re:ANSI C (4, Insightful)

IversenX (713302) | more than 5 years ago | (#26950681)

Because you can't compile a mathematical definition.

If we imagine that the hash function came only as a mathematical definition, how would your test your new implementation in LangOfTheWeek is correct?

Well, you have 2 options. One, you can prove that your program behaves, in every important way, the same as the definition. This is long, tedious work, and most programmers don't even have the necessary skills for this. Two, you can make a reference implemention in some other language, and compare the outputs.

Now, given, say, 100 programmers each working on their own functions, we should have 1 resulting behaviour. This will mean that everybody implemented the algorithm 100% correctly. However, the actual number will be between 1 and 100, depending on the skills of the programmers, and the care they've taken in implementing the functions.

Now, what's the result here? (no pun intended). It's likely to be chaos.

That's why it's very convenient to have a single reference source.

Re:ANSI C (0)

Anonymous Coward | more than 5 years ago | (#26950943)

The actual number of correctly implemented algorithms as done by 100 programmers will be between 0 and 100, not 1 and 100.

Re:ANSI C (0)

Anonymous Coward | more than 5 years ago | (#26951385)

The actual number of correctly implemented algorithms as done by 100 programmers will be between 0 and 100, not 1 and 100.

How about learning to read? He didn't say the number of correct implementations, he said the number of different behaviours.

Re:ANSI C (0)

Anonymous Coward | more than 5 years ago | (#26951525)

Obviously, for a programmer (and hopefully also for a cryptoanalyst) the output of a hash function looks random by default. That is: the *value* of the hash method is random.

But that's not true for the size of the output, the size of the intermediate states, the places where pointers should point to etc. etc.

So in that view, it's very possible to test a hash method implementation. If you have to *at this stage* is another question. I'll probably read about it in the next threads.

Difference between "program" and "mathematics"? (1)

tepples (727027) | more than 5 years ago | (#26953447)

Because you can't compile a mathematical definition.

If you've read the works of E.W. Dijkstra (start with Cruelty [utexas.edu] ), you'd understand that a programming language isn't much more than a formal system for expressing mathematical definitions. Perhaps Haskell or another purely functional language might fit your intuitive understanding of a "mathematical definition" better than a procedural language like C, C++, P*, or Java.

Reference implementation (4, Informative)

rgmoore (133276) | more than 5 years ago | (#26950723)

In a word, no. A reference implementation is supposed to be a working version of the code, not just a mathematical description. With a working version, it's possible to do things like test its real world performance or cut and paste directly into a program that needs to use the function. That's obviously only possible if you have a version that works on real-world processors.

Consider Skein as an example. One of the things that Bruce Schneier described as a major goal of its design is that it uses functions that are highly optimized in real-world processors. That means that it's possible to make a version that's both very fast and straightforward to program, an important criterion for low-powered embedded applications. You won't discover that kind of detail until you implement it.

Re:Reference implementation (1)

certain death (947081) | more than 5 years ago | (#26953537)

We all know why Bruce's code came out clean...he is actually the Messiah!!! Or at least in the circles I run in he is! :o) Queue the Chuck Norris jokes with Bruce in stead of Chuck.

Re:ANSI C (2, Informative)

xquark (649804) | more than 5 years ago | (#26950767)

Mathematically anything is feasible, however if you place a real-world constraint such as it requiring an implementation then that greatly narrows the field down.

Furthermore one of the judging factors is the speed and portability of the algorithm upon a wide variety of commonly used platforms - it doesn't make sense to come up with a super-cool hash function that only works well on say an x86.

The short of it is that people make mistakes from time to time, and it is true that perfection is an important factor in crypto-code so the submitters should have been more thorough, From the article it seems that the overwhelming majority of them were - which is a positive.

Re:ANSI C (2, Insightful)

thue (121682) | more than 5 years ago | (#26950791)

An implementation in a programming language is the a way to define a function mathematically.

That is what a programming language is - a way to precisely define an algorithm.

But C is a low-level language, and therefore maybe a bad choice for function definitions. Instead, in my experience, implementing an algorithm in a high-level functional language like Haskell will often result in a beautiful and readable mathematical function definition.

Re:ANSI C (0, Troll)

iwein (561027) | more than 5 years ago | (#26951381)

Yes, it would be nice to have a way to compile beautiful mathematical functions to machine code. Sadly you're dependent on those people that are writing the grammar and reference implementation of the compiler. What if they need one of those pesky algorithms for that?

Re:ANSI C (1)

DamnStupidElf (649844) | more than 5 years ago | (#26952015)

What if they need one of those pesky algorithms for that?

Look up bootstrapping. Most modern compilers can compile themselves using a stage or two of simpler compilers, built with either an existing compiler, an assembler, or maybe some hand written machine code. All the important parts of the compiler (parser, optimizer, etc.) can be written in the same language that the compiler can compile.

Trusting trust (1)

tepples (727027) | more than 5 years ago | (#26953497)

Look up bootstrapping. Most modern compilers can compile themselves using a stage or two of simpler compilers

Look up trusting trust [bell-labs.com] . Defects in the compiler, whether intentional or unintentional, can propagate themselves to the compiled work, even if the compiled work is the compiler itself.

Re:ANSI C (2, Insightful)

setagllib (753300) | more than 5 years ago | (#26953383)

C is a bad choice for mathematical function definitions, but it's a fantastic choice for integrating into virtually any stage of a software project. It can be used in an OS kernel, a standard portable crypto library (e.g. OpenSSL), embedded firmware, what have you. All of this with NO more library dependencies than the bare minimum memory management, and most crypto/hash functions don't need those because their state fits in a fixed-size structure. So you can have the mythical 100% standalone C code that fits in any context.

Implementing the algorithm in C from the start also makes it easy to port to C-like languages like Java and C#.

cryptol (3, Interesting)

jefu (53450) | more than 5 years ago | (#26951633)

But that just raises the question of how to define a hash function mathematically? The lambda calculus, Godel Numbers? Things like cryptographic hash functions don't tend to be nice algebraic thingies like f(x)=x*x+7, especially since they're usually iterative and deliberately messy - the pretty functions are likely to be less secure.

On the other hand, there are things like cryptol [galois.com] in which you may be able to specify hash functions more mathematically. For example, here is a cryptol implementation of skein [galois.com] .

Re:ANSI C (1)

johanatan (1159309) | more than 5 years ago | (#26954635)

Why not just use a functional language like Haskell and you'd have both the implementation and the 'mathematical definition' in one fell swoop.

Re:ANSI C (-1, Troll)

Anonymous Coward | more than 5 years ago | (#26950609)

Blame open source, not the language. This is the typical crap that comes out of FOSS projects -- unchecked boundary conditions, buffer overflows, sloppy (or non-existent) error handling. Trust me, even if they coded this stuff in Ada or Perl, they would have fucked it up. Frankly, I'm surprised most of them even compiled without lint warnings.

Re:ANSI C (0)

Anonymous Coward | more than 5 years ago | (#26950721)

One word: VALGRIND.

Seriously, it should get 90 percent of these problems, and I'd imagine it gets 100 percent of the 'normal' screwups.

Re:ANSI C (1)

FormOfActionBanana (966779) | more than 5 years ago | (#26950837)

Oh, interesting. VALGRIND [valgrind.org] looks like dynamic analysis. The results in the article are from static analysis. Each is really useful, but they tend to find different sorts of problems.

If you'd like to download the five problematic submissions and run VALGRIND against them, please email me the results. I'd be interested to see what is actually detected.

Re:ANSI C (1)

ion.simon.c (1183967) | more than 5 years ago | (#26951451)

If you'd like to download the five problematic submissions and run VALGRIND against them, please email me the results. I'd be interested to see what is actually detected.

*seconds the request*
$MY_SLASHDOT_USERNAME at gmail

Re:ANSI C (0)

Anonymous Coward | more than 5 years ago | (#26951193)

obviously you never worked within a corporation writing closed apps before.. some of the diseased code coming out of THOSE projects was positively toxic..

Re:ANSI C (5, Insightful)

Anonymous Coward | more than 5 years ago | (#26950683)

What did they get? You realize this is just an ad for Fortify, right? Out of 42 projects, they found 5 with memory management issues using their tool. Maybe instead of switching to SPARK, the 5 teams that fucked up could ask the 37 that didn't for some tips on how to write correct C.

Re:ANSI C (-1, Troll)

Anonymous Coward | more than 5 years ago | (#26950887)

Mod parent up. Thanks. Annoying SLASHVERTISEMENT!

PS: (1, Funny)

Anonymous Coward | more than 5 years ago | (#26950997)

The alternative was supposed to be throwing money at Fortify by the way. If your conclusion is to switch to SPARK then Fortify needs to work on their PR, *cough*, I mean blogging.

dandelion orchard (3, Insightful)

epine (68316) | more than 5 years ago | (#26951935)

This just emphasizes what we already knew about C, even the most careful, security conscious developer messes up memory management.

I know nothing of the sort. How about asking some developers who have a history of getting both the security and the memory management correct which intellectual challenge they lose the most sleep over?

The OpenBSD team has a history of strength in both areas. I suspect most of these developers would laugh out loud at the intellectual challenge of the memory management required to implement a hash function. It's about a hundred thousand lines of code short of where the OpenBSD team gets grey hair over memory management problems in the C language.

I was just having an intense conversation about restrictive land covenants with my GF. If the economic cycle tips downward, the covenant holder (often a not-for-profit manila file folder which is legally distinct from the insolvent main entity) ceases to afford regular maintenance. Suddenly it turns into a dandelion orchard, and everyone in the community is dead certain that every dandelion on every lawn originated from this single source, whereupon some soon to be re-elected politico harpoons the legal infrastructure that permitted these things to flourish in the first place.

"What we know about C" and "what we know about dandelions" are surprisingly equivalent.

I wouldn't hire a programmer who can't get memory management right to take on any significant intellectual challenge. It's just a way to feel good about yourself without having the aptitude to cut your way out of a wet paper bag.

90% of software development projects are not aptitude driven. Let's stop fooling ourselves into thinking that the languages that work well in those contexts having anything to offer those of us dealing with the other 10%

Memory management is a subcase of resource management with a particularly harsh way of delivering the news: you suck. A memory managed language deprives the environment of so many golden opportunities to deliver this message, despite the fact that you still suck. By the time you don't suck, you've ceased to regard unmanaged memory as a core intellectual challenge, and trained yourself to work within an idiom where you hardly ever get it wrong anyway.

The C string functions that cause the worst of the grief were widely known to be a bad idea by the mid 1980s. They originated a point in history where linking sprintf() was sometimes considered a luxury you couldn't afford. In the microcontroller world, it's still common that an environment provides three different versions of printf/sprintf: basic, basic plus more of the format options and maybe long integers, and then the full version which also includes floating point. The middle option is the beer budget. The first option is for when you can't even afford beer. These micros are not so different that the mini-computers on which C and Unix were originally created.

Furthermore the efficiency of the string functions tends to ripple outward, as they tend to carry the torch for the platform's memory subsystem performance in most C code bases. What do the Z80, 6809, and 8086 all have in common? Instruction set tweaks to make zipping along a string of bytes a lot zippier.

These tricks are then rolled into vendor optimized string libraries and made available to the developer via the ratified ANSI C string functions.

It's unfortunate that all this industry of tweaking toward core performance was consolidated under a string API whose modern legacy is to have informed so many programmers that "you suck" that the general sentiment is to vote it off the island, as if such a thing is possible with a cockroach or a rat or dandelion dandruff.

Re:dandelion orchard (0)

Anonymous Coward | more than 5 years ago | (#26952269)

You should be modded up very badly.

It is more serious in this case because whomever gets elected will see his algorithm becoming the next standard for secure hashes.

I do not want to trust my data to an algorithm nobody can fully understand, written by somebody who cannot manage to learn that if you allocate 3 memory positions and indexes start at 0 there won't be a position number 3.

If there is something good about C is that all of its problems are well known and documented. Someone incapable to use C correctly will accidentally the whole encryption object in Java or the whole encryption parentheses in Haskell.

I am sorry but a programming language won't make you less of a retard.

Re:dandelion orchard (3, Insightful)

Luke has no name (1423139) | more than 5 years ago | (#26953323)

What I get out of this:

"We're going to give you more shit to think about by making you use C. if you can't deal with all the stupid shit C throws at you, you suck."

Which is a shit argument. Just use a better language that gives people less to worry about, and develop from there. Having to debug the shit out of a program for obscure memory management issues shouldn't be a test of your competence. You should be able to focus on the task at hand, nothing else.

Re:ANSI C (4, Insightful)

OrangeTide (124937) | more than 5 years ago | (#26950835)

That is what they get for mandating the code be in ANSI C.

Because most of the systems out there use C for the performance sensitive bits. (and when asm optimization is done, people generally use a C implementation as a reference since C and asm are similar in many ways).

When they start doing Linux and Windows and other popular systems primarily in Ada you can start going WTF over people posting ANSI C code. Until Java, Ruby and Python aren't dependent on C/C++ implementations for their functionality we'll just have to suffer with C.

Re:ANSI C (0)

Anonymous Coward | more than 5 years ago | (#26952123)

I think we should all use java interpreters, that are written in java.

It would take the computer 3 days to boot, but they would be ultra secure, because of no memory leaks, thanks to the java virtualization environment.

Re:ANSI C (2, Interesting)

setagllib (753300) | more than 5 years ago | (#26953457)

I hate to have to repeat it for the thousandth time, but Java's so-called virtualization comes crashing right down if you have even a single threading bug. Let me explain how it works.

Java gets compiled to machine code at runtime. Unlike machine code made from C code, the machine code really does have some nice protections from address and type confusion, with a generally acceptable performance penalty.

However it does NOT have ANY protections from threaded race conditions, so if you make any mistake in this, all bets are off as the results are completely undefined. It could be as simple as a missed increment, or it could cause an internal JVM data structure to be corrupted, either in the Java or C++ components.

At least with C you see and control all of the code that gets run at runtime, all with debug symbols right down to the system calls, and can largely detect and sometimes even trace problems, but with the monstrously large JVM running under your code, you'd be lucky to get a meaningful stack trace.

The same applies right back to security. Threading bugs are generally much more difficult to diagnose and solve than memory management bugs, so if a developer gets memory wrong, they'll get threading wrong too. In a kernel it's worst of all. A Java kernel does little to solve this, and in fact would include a lot of JVM code which must also be debugged.

Re:ANSI C (1)

OrangeTide (124937) | more than 5 years ago | (#26953881)

memory leaks are not a security issue. You're thinking of buffer overflows.

Why Java and not Haskell, Erlang, or Lisp? which also have these features and then some?

I would take DbC as an important language feature over some "ultra secure" memory idea that seems to have little real world value.

Re:ANSI C (1)

nedlohs (1335013) | more than 5 years ago | (#26950925)

Because you want vendors to just use the reference code, without screwing it up by implementing their own C version from the ADA reference code.

Re:ANSI C (3, Insightful)

Anonymous Coward | more than 5 years ago | (#26951343)

That is what they get for mandating the code be in ANSI C. How about allowing reference implementation in SPARK, ADA or something else using design-by-contract. After all, isn't something as critical as a international standard for a hash function the type of software d-b-c was meant for?

C is the lowest common denominator. Once you have a library in C that's compiled to native code, you can link just about any other language to that library: Perl, Python, Ruby, Java, Lisp, etc., all have foreign function interfaces to C.

C also can compile to just about any processor out there: x86, SPARC, POWER, ARM, etc. Over the decades it's become very portable and optimized.

C is also know by a large subset of the programmers out there, so if people want to re-write the algorithm in another language, they can start with the C code directly, or with the formal specification and then use the C as a comparative reference.

Re:ANSI C (0)

Anonymous Coward | more than 5 years ago | (#26951751)

Something as critical as an international standard for a hash function must be initially implemented in an extremely commonly-used and read language like C.

Even supposing for a moment that languages such as SPARK or ADA were so well designed that programs written in them were devoid of implementation bugs (such as buffer overruns, as opposed to algorithm design bugs), the fact that they are arcane and unreadable by the vast majority of programmers, especially including those who we want to be evaluating and thinking about the hash functions themselves, completely disqualifies those languages as useful in that context.

Another advantage of using C as the initial reference implementation is that not only is the hash function evaluated, but fine-tooth-comb debugging of the implementation in one of the most common languages that the hash will be needed in is had for "free".

Re:ANSI C (3, Insightful)

swillden (191260) | more than 5 years ago | (#26952583)

After all, isn't something as critical as a international standard for a hash function the type of software d-b-c was meant for?

No.

The key desirable characteristics of a good secure hash function are (in this order):

  1. Security (collision resistance, uniformity)
  2. Performance
  3. Ease of implementation

If the NIST AES contest is any example, what we'll find is that nearly all of the functions will be secure. That's not surprising since all of the creators are serious cryptographers well-versed in the known methods of attacking hash functions, so unless a new attack comes out during the contest, all of the functions will be resistant to all known attack methods.

With security out of the way, the most important criterion that will be used to choose the winner is performance. This means that every team putting forth a candidate will want to make it as fast as possible, but it still has to run on a few different kinds of machines. The closer you get to the machine, the faster you can make your code -- and this kind of code consists of lots of tight loops where every cycle counts. But assembler isn't an option because it needs to run on different machines.

That leaves C as the best choice. It's the portable assembler.

Re:ANSI C (0)

Anonymous Coward | more than 5 years ago | (#26953489)

If you're going to talk about Ada, at least spell it correctly. I don't know about you, but I'd certainly have trouble writing code in a language called ADA (Amercians with Disabilities Act).

Re:ANSI C (0)

Anonymous Coward | more than 5 years ago | (#26954323)

You're an idiot. Nothing wrong with using the language that 99.99% of all software can easily use. The C ABI is the ABI that every damn thing on the planet can interface with.

this is why... (-1, Flamebait)

Anonymous Coward | more than 5 years ago | (#26950653)

... unmanaged code is dead. If you're still writing unmanaged code, you get what you deserve. It's 2009, not 1989.

Re:this is why... (2, Funny)

SoapBox17 (1020345) | more than 5 years ago | (#26950757)

Yes, I can't wait for managed Linux to come out. That sounds like a great idea....

Re:this is why... (2, Interesting)

Cyberax (705495) | more than 5 years ago | (#26950897)

Re:this is why... (0)

Anonymous Coward | more than 5 years ago | (#26951099)

My respect for Microsoft (represented as a percent) just had an underflow error and is now equal to zero.

Microsoft talking about reliable systems as though they know what they're talking about?

Re:this is why... (0)

Anonymous Coward | more than 5 years ago | (#26952369)

Microsoft research is not the Microsoft you know. They are not bound by 28 years of incompatibility. There main purpose is to remove the brains of the hands of the other companies...

Re:this is why... (0)

Anonymous Coward | more than 5 years ago | (#26954495)

Its OK to admit you're incapable of understanding kernel design. There are plenty of idiots like you.

Go peddle your FUD somewhere else.

probably wouldn't be bad for a lot of applications (1)

Trepidity (597) | more than 5 years ago | (#26951073)

At the very least, using a C-like language with safety, like Cyclone [thelanguage.org] , would be a reasonable performance/safety tradeoff for a lot of users compared to the current tradeoffs (which leave quite a bit to be desired [cormander.com] ). I'm guessing the main stumbling block would be reimplementation overhead (Linux already exists in C, has a lot of code, and is a fairly quickly moving target) and lack of interest on the part of kernel hackers (who have little interest in using non-C languages), rather than performance of the resulting system.

Re:this is why... (0)

Anonymous Coward | more than 5 years ago | (#26951285)

eventually, some code has to do the memory management, whether it's in C, asm, or some HDL. You cannot escape this no matter how many pointless layers of code you place between the program and hw. Modern OS's are supposed to do this, the ones that don't do it right being broken, making so-called 'managed code' redundant. All it does is take excess resources, slowing things down. They might be quick to develop, but they are slow to execute, making the user experience a living hell. Because of this, I avoid 'managed' applications whenever possible. Yuck.

Re:this is why... (3, Insightful)

tepples (727027) | more than 5 years ago | (#26953863)

If you're still writing unmanaged code, you get what you deserve. It's 2009, not 1989.

Try running managed code in the 4 MB RAM of a widely deployed handheld computer. Now try making that managed code time-competitive and space-competitive with an equivalent program in C++ compiled to a native binary.

Disclaimer (2, Interesting)

FormOfActionBanana (966779) | more than 5 years ago | (#26950733)

I should add that I work for Fortify and that I initiated the SHA-3 review in my spare time as a private project. The Slashdot article on December 21 caught my interest.

Re:Disclaimer (1)

Compholio (770966) | more than 5 years ago | (#26950807)

I think that since only 5 of the 42 projects garnered your attention that a better quote to include in the summary would have been:

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.

If the other 37 projects didn't have any signficant flaws on the first round of this contest then that doesn't say to me "well, obviously no-one can do memory management properly" - it says that people make mistakes.

Re:Disclaimer (3, Interesting)

FormOfActionBanana (966779) | more than 5 years ago | (#26951075)

Yeah, both very good points.

People do make mistakes. Even geniuses, when they're trying really hard to be careful. Personally, I see recognizing that as a validation for code review (including the automated code review that I do).

I want the winning entry for this competition to be flawless to the extent that's feasible. Right now, my job includes finding SHA-1 for cryptographic key generation, and telling people to replace that with something better. I don't want to be pulling out SHA-3 in a couple years, too.

Re:Disclaimer (0)

Anonymous Coward | more than 5 years ago | (#26953369)

Are you sure that the SHA-1 vulnerabilities apply here? You don't have much use for pre-image attacks against key generation. You could even argue that for (session) key generation, the whole hash method does not matter much anyway.

That said, replacing SHA-1 with SHA-2 is good for all applications except those that are bound because of interoperability (legacy) applications, hardware and/or strict performance requirements.

Re:Disclaimer (1)

Rayban (13436) | more than 5 years ago | (#26950909)

So which of the vulnerabilities did you hold back on so that you can exploit it in a couple of years? ;)

Re:Disclaimer (1)

jd (1658) | more than 5 years ago | (#26954219)

I think that was the article I submitted, expressly with the intent that it would catch the attention of people like yourself who could contribute to the auditing. This improves the quality of the submissions, perhaps identifies flaws in algorithms, and in general leads to a better contest between better competing implementations.

Personally, I'm gloating a little because the functions I considered to have such cool names (eg: Blue Midnight Wish) all came through clean and are also listed on the SHA3 Zoo as clean - for now. On the other hand, the ones listed on one or both sites as flawed have boring names.

Who's this Bruce Shneieier guy? (5, Funny)

Anonymous Coward | more than 5 years ago | (#26950737)

"... because implementation is where people screw up."
"Bruce Schneier's Skein, ... came through defect-free."

So by deductive logic, Bruce is a robot. Also previously slashdotted.

Re:Who's this Bruce Shneieier guy? (1)

jd (1658) | more than 5 years ago | (#26954569)

No, all it proves is that he's not a person. This leaves all advanced alien lifeforms, artificial intelligences and supernatural phenomena as possibilities.

Hardly "memory management" (3, Insightful)

SoapBox17 (1020345) | more than 5 years ago | (#26950787)

From TFA (and TFS):

This just emphasizes what we already knew about C, even the most careful, security conscious developer messes up memory management.

This doesn't follow from TFA. The blog points out two instances of buffer overflows. The first one you could argue they messed up "memory management" because they used the wrong bounds for their array in several places... but they don't sound very "careful" or "security conscious" since checking to make sure you understand the bounds of the array you're using is pretty basic.

But that's not what bothered me. The second example is a typo where TFA says someone entered a "3" instead of a "2". In what dimension is mis-typing something "messing up memory management"? That just doesn't follow.

Re:Hardly "memory management" (0)

Anonymous Coward | more than 5 years ago | (#26950931)

Exactly, how are we supposed to trust their algorithm that is barely understandable by 1 in 400 million people when they cannot get a simple C program right?

Re:Hardly "memory management" (1)

drinkypoo (153816) | more than 5 years ago | (#26951109)

In what dimension is mis-typing something "messing up memory management"? That just doesn't follow.

I haven't evaluated the code in question, because math scares me, but if someone makes a fencepost error (or just a typo - but fenceposting is a common cause of off-by-one errors) it's entirely possible to be mucking with memory that is a byte or a page off from the memory you think you're working on. So that's an example of how mis-typing something could cause an error in memory management (if in one function you have it right, and in another you have it wrong... you can't even get it right by getting lucky. although getting it right by getting lucky is the kind of thing that causes strange transient failures in other parts of the program way down the road somewhere.)

Re:Hardly "memory management" (1)

FormOfActionBanana (966779) | more than 5 years ago | (#26951319)

drinkypoo the math is as easy as 3 >= 3. See here:

// deal with the length update first
                bcount = ss.sourceDataLength; // previous length
                ss.sourceDataLength = bcount + databitlen; // new 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.

And the problem (in Blender.c:1808) is because of here, in the array's declaration:


                DataLength sourceDataLength2[3]; // high order parts of data length // note: the array size determines the maximum length supported

In C, the array blah[3] has three elements: blah[0], blah[1] and blah[2]. Accessing blah[3] is just random memory and might actually be in use for something else.

In defense of C (4, Insightful)

phantomfive (622387) | more than 5 years ago | (#26950937)

The summary is kind of a troll, since most of the submissions actually managed to get through without ANY buffer overflows.

Buffer overflows are not hard to avoid, they are just something that must be tested. If you don't test, you are going to make a mistake, but they are easy to find with a careful test plan or an automated tool. Apparently those authors who had buffer overflows in their code didn't really check for them.

C is just a tool, like any other, and it has tradeoffs. The fact that you are going to have to check for buffer overflows is just something you have to add to the final estimate of how long your project will take. But C gives you other advantages that make up for it. Best tool for the job, etc.

Re:In defense of C (0)

Anonymous Coward | more than 5 years ago | (#26951771)

So true. I've generated an implementation of one of the submissions in Java. Of course, it's very unlikely to have overflows. The only way to have overflows in Java is to have one in the JVM, or to play around within byte arrays yourself (something only a horrid C++ programmer would do to Java).

Then again, a cryptographic method is something in which it pays to have it in native code. OpenSSL certainly beats the Java implementations hands down. You use SSE instructions and have a smart management of registers when coding in C or assembly. I've seen a Java implementation of MD5 beat md5sum, but otherwise for SHA1, SHA2 or any other cryptographic primitive C/C++ will beat Java if correctly programmed for performance.

C/C++ or assembly hasn't got (automated) runtime checking. IMHO, any static code analysis that is available should be used for *any* C/C++ project. Not doing so is really unforgivable, and doubly so when implementing security primitives. You cannot depend on smartness of the application programmer here; this point has been proven over and over again.

Actually, within my company it is not even done any more to compile Java without static code analysis. I've just looked at some 3rd party code with checkstyle after converting it to Java 5, and you'd be amazed what kind of errors show up. 30 lines of code (excluding whitespace) and you find 10 hard errors, although I must admit that the code was created with haste and - amazingly - kind of worked.

Re:In defense of C (0)

Anonymous Coward | more than 5 years ago | (#26953169)

Note: with "horrid C++ programmer" I mean a horrid programmer that normally uses C++. I'm not trying to bash C++ pogrammers (I would get killed by my collegues).

Re:In defense of C (3, Insightful)

Kjella (173770) | more than 5 years ago | (#26952503)

Buffer overflows are not hard to avoid, they are just something that must be tested.

No, they're a huge pain in the ass 99% of the time, what's worst is that pointers work even when they absolutely shouldn't. I recently worked with some code that instead of making a copy of the data just kept a void pointer to it instead. Since that code was passed just a temporary variable that was gone right after being passed into it, it should error out on any sane system, but the problem is it worked - when it was called later, using the pointer to a temp that's alreday gone it would just read the value out of unallocated memory anyway, and since the temp hadn't been overwritten it worked! Only reason it came up was that when called twice it'd show the last data twice, since both would be pointing to the same unallocated memory location. It's so WTF that you can't believe it. Personally I prefer to work with some sort of system (Java, C#, C++/Qt, anything) that'll give you some head's up that will tell you're out of bounds or otherwise just pointing at nothing.

Re:In defense of C (1)

owlstead (636356) | more than 5 years ago | (#26953225)

I don't think the performance estimate will change much. You only have to check the input, and the complexity is within the rounds of the underlying block cipher/sponge function or whatever is used to get the bits distributed as they should be.

I blame the bugs on tight time schedules and inexperienced programmers/insufficient review. Basically, cryptographers are mathematicians at heart. There is a rather large likelyhood that C implementations are not their common playing field.

C isn't the problem, it is really... (3, Insightful)

MobyDisk (75490) | more than 5 years ago | (#26951135)

I suspect the problem is related to the poor coding practices used in academia. I see college professors who write code that barely compiles in GCC without a bunch of warnings about anachronistic syntax. Some of the C code used constructs that are unrecognizable to someone who learned the language within the past 10 years, and is completely type unsafe.

I can't tell much from the code on the link, but I do see #define used for constants which is no longer appropriate (yet is EXTREMELY common to see). C99 had the const keyword in it, probably even before that.

Re:C isn't the problem, it is really... (2, Insightful)

FearForWings (1189605) | more than 5 years ago | (#26951423)

I suspect the problem is related to the poor coding practices used in academia. I see college professors who write code that barely compiles in GCC without a bunch of warnings about anachronistic syntax.

You know you'll learn a lot in a class when, after being told at the very least his c++ code is using deprecated includes, the professor tells you to just use '-Wno-deprecated'. I've basically come to the conclusion that I am just paying the school for a piece of paper, and I will learn little outside my personal study.

Re:C isn't the problem, it is really... (1)

Nigel Stepp (446) | more than 5 years ago | (#26951661)

That depends, what is the class for? If it's a class teaching how to use C++, then you have a point.

If it's just about any other CS class, however, probably the language you are using doesn't matter so much, but rather what you are using the language to do.

I'm guessing that in this instance, the fact that the professor is using some wacky set of C constructs is not nearly as important as what is actually being taught, e.g. an algorithm. That is, ignore the deprecated stuff because that's not what is important.

Of course, yes, it could just be a really bad professor :)

Re:C isn't the problem, it is really... (1)

stinerman (812158) | more than 5 years ago | (#26951507)

Oh those were the days. At least my prof explained the difference.

With a #define, the preprocessor picks up the constant while using const delays it to the compiler. Of course, he said they were equally good, just a matter of style.

We never did learn why we had to put

using namespace std;

near the top of the program other than because we were supposed to use the standard namespace. I never bothered to ask or find out because by that time I had realized I'm an atrocious programmer and wouldn't be doing that for a living.

Re:C isn't the problem, it is really... (1)

olderphart (787517) | more than 5 years ago | (#26951517)

Prithee sirrah, dost claim thou kennst Anglic nor can ye reck my speech? Poltroon! Ye but float on the surface and fathom not the depths. Fie, fie upon your presumption -- hasten ye hence from this my good greensward!
--
olderphart
while (--t > 0) live();

Re:C isn't the problem, it is really... (2, Informative)

jgrahn (181062) | more than 5 years ago | (#26951725)

I can't tell much from the code on the link, but I do see #define used for constants which is no longer appropriate (yet is EXTREMELY common to see). C99 had the const keyword in it, probably even before that.

C got const much earlier; it was there in 1989. And at least in the past, a static const int FOO was less useful than #define FOO, it wasn't "constant enough" to define the size of an array. But yes, you see macros too often.

Re:C isn't the problem, it is really... (0)

Anonymous Coward | more than 5 years ago | (#26951733)

Are you some kind of fucking C++tard?
#define is THE MOST APPROPRIATE method of defining constants in C. If you don't know how to use it you don't know how to use const either. Hint: it doesn't do what you think it does.

Re:C isn't the problem, it is really... (0)

Anonymous Coward | more than 5 years ago | (#26952989)

There are compilers shipping this very day where using a static const int will produce worse code than using #define. Zilog and their ZDS II comes to mind. Not that their platform is not a big clusterfuck anyway.

Their version 4.9.6 from a couple years ago (that's 4th major release, right?) had a linker that would issue *warnings* on undefined symbols (so that the binary was rubbish, with a bunch of zeros where the missing relocations would go.

Their current version 4.11.0 has an assembler/linker which will happily produce *no* diagnostics for constant address expressions that are (so it seems) unsupported by the object file format and result in zeroes being emitted to the binary file instead of the address you had in mind.

I agree, though, that in an academic setting all profs should know a current programming language well. I'm taking a numerical methods course, where the prof, although a good scientist and mathematician otherwise, writes absolutely horrible code in both F77 and Matlab... Horrible as in willy-nilly global variables, hidden state in functions via static variables (call f(reset), then f(some set-up stuff), some more, then f(reset) before you use f() for a new "job"), etc...

Re:C isn't the problem, it is really... (0)

Anonymous Coward | more than 5 years ago | (#26953525)

Using const as a replacement of #define in C99 for numerical constants???

Go read the norm again... Then you will be able to see what the exact semantic of const is, what this imply, in which cases this is appropriate and in which cases this isn't.

This is sad seeing people giving lessons to other, yet not knowing well what they are talking about.

Re:C isn't the problem, it is really... (0)

Anonymous Coward | more than 5 years ago | (#26954169)

How about embedded platforms where there are plenty of definitions, and limited memory space? Do you want to allocate space for every single constant (of which there can be thousands), or just use a #define, which places the number in the actual assembly?

Honestly, nothing could be more tr

fuck... (-1, Offtopic)

Anonymous Coward | more than 5 years ago | (#26951611)

Www.aNti-slash.org fly They looked Lesson and documents like a

uhh, lint... (3, Informative)

mevets (322601) | more than 5 years ago | (#26952437)

$ cat bo.c
int a[3];
void f()
{
                a[3] = 1;
}

$ lint bo.c
bo.c:4: warning: array subscript cannot be > 2: 3

Lint is so basic, I can't imagine not using it....

Re:uhh, lint... (1, Insightful)

Anonymous Coward | more than 5 years ago | (#26952515)

static int a[3], b = 3;
void f(void)
{
  a[b] = 1;
}

Lint isn't magic.

Re:uhh, lint... (1)

mevets (322601) | more than 5 years ago | (#26953779)

no lint is basic, so basic there is no good reason to not always use it. (bo.c) is equivalent to the only flaw described in the published summary. Dynamic analyzers (required to catch your example) are just stuck in the shadow of the halting problem.

Where is lint? (1)

tepples (727027) | more than 5 years ago | (#26953839)

Lint is so basic, I can't imagine not using it....

Lint is not found in Ubuntu. Did you mean Splint? And can you recommend anything analogous for C++ programs, for which Splint has no front-end?

memory leak... WTF??? (0)

Anonymous Coward | more than 5 years ago | (#26953575)

why the fuck dynamic memory allocation is used in a C implementation of a hashing algorithm?

Other SHA-3 news: conference starts this week! (1)

secmartin (1336705) | more than 5 years ago | (#26954899)

In other news, the first SHA-3 conference will be held in Belgium this week. The NIST hopes to be able to reduce the amount of contestants for the SHA-3 contest to a more manageable level by the end of that; for more info read on here [securityandthe.net] .
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...