Re: Clearing sensitive in-memory data in perl
Generally speaking, I think software with a security impact should not be written in C. Hooey. The C language is not the problem. The C library is not the problem. Both of these things were fixed during ANSI standardization, so that standard-conforming programs will not fail runtime checks for overrunning arrays (strings are just arrays of characters). There have been various C implementations that did these checks, including both compilers and interpreters. Some are free, some are proprietary. (I proposed to fund adding these checks to GCC, but the price I was quoted was too high for me.) I fault the people who don't use such tools -- not the C language. (Aside: What ever happened to Saber C? Oh, it was renamed to Centerline CodeCenter, never made it out of the Unix workstation market, used FlexLM per-cpu licensing crap, has gone morbid, and was acquired a year ago by ICS.com, a graphics library company, with a promise to port it to Linux. There's no evidence of such a port, and the product support matrix was last updated in June 2001. The product doesn't appear on ICS's product pages. I wonder how cheaply the source could be bought and freed up, to bring it back to life? It was a nice product, fifteen years ago.) The reason there's fewer security bugs in PL/1 programs than C programs is because almost nobody has written programs in PL/1 since about 1985. Google did find me a compiler you can download -- it runs on VMS, on Vaxes or Alphas. Anybody still running those space-heaters is welcome to program in PL/1. The rest of us have real work to do, and it's likely to get done in C or C++. John - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: ECC patents?
-- Whyte, William [EMAIL PROTECTED] $25MM figure: http://lists.jammed.com/ISN/2003/10/0097.html I stand corrected. However as was pointed out previously: : : Further, the license would be limited to only : : prime field curves where the prime was : : greater than 2255. On the NIST list of curves : : 3 out of the 15 fit this field of use: the : : prime field curves with primes of 256 bits, : : 384 bits and 521 bits. Of the NIST list of fifteen, nine are 256 bits or longer. Presumably, if NSA thought certicom had a case, they would have licensed at least the other six NIST curves as well, and most likely the other twelve. The three curves that are licensed look different from the other twelve, though I have no idea of the significance of this, if any. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG ZKrN4sA2qyTNIC90h3U/8Er848IPFGfUOQyBxm8h 4xlZJBIqZwgUkOyqgxTzTBcauENSjU46x6oDgn2X4 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Clearing sensitive in-memory data in perl
Victor Duchovni wrote: On Thu, Sep 15, 2005 at 08:51:02PM -0700, Bill Frantz wrote: On 9/13/05, [EMAIL PROTECTED] (Perry E. Metzger) wrote: Generally speaking, I think software with a security impact should not be written in C. I agree. I also note that Paul A. Karger and Roger R. Schell, in their paper, Thirty Years Later: Lessons from the Multics Security Evaluation state: While some of the fault is perhaps in the core language, my contention is that the real problem is the anemic standard C-library. When working on C projects that have (and uniformly use) their own mature string handling libraries (I was a contributor to Tcl in the 90's and am now working in Postfix) I found that buffer overflows (and with Tcl for reasons I won't go into here also memory leaks) were a non-issue in those systems. With either Tcl_DString or VSTRING (Postfix), one simply loses the habit of needing to keep track of buffer lengths. When combined with a compatible I/O interface (say VSTREAM), argument vector library (ARGV) hash table library, ... one no longer in practice manipulates bare null-terminated string buffers except when passing (usually read-only) content to system calls via the C-library. I continue to write code in C, free of buffer overflows and memory leaks, not because I am more manly than the next programmer, but because I am attracted to working on well-designed systems, whose designers took the time to develop a richer set of idioms in which to construct their work. My view is that C is fine, but it needs a real library and programmers who learn C need to learn to use the real library, with the bare-metal C-library used only by library developers to bootstrap new safe primitives. So wouldn't the world be a better place if we could all agree on a single such library? Or at least, a single API. Like the STL is for C++. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
European country forbids its citizens from smiling for passport photos
Do you really need to click on this link to know which one it is? http://cbs5.com/watercooler/watercooler_story_258152613.html I guess we should give neutral facial expressions for the photo, then smile (or frown) while in the airport Sounds like the technology (still) isn't ready for prime time. (seen at http://isthatlegal.org) -- William Allen Simpson Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Clearing sensitive in-memory data in perl
On Sat, Sep 17, 2005 at 11:53:20AM +0100, Ben Laurie wrote: My view is that C is fine, but it needs a real library and programmers who learn C need to learn to use the real library, with the bare-metal C-library used only by library developers to bootstrap new safe primitives. So wouldn't the world be a better place if we could all agree on a single such library? Or at least, a single API. Like the STL is for C++. Yes, absolutely, but who is going to do it? -- /\ ASCII RIBBON NOTICE: If received in error, \ / CAMPAIGN Victor Duchovni please destroy and notify X AGAINST IT Security, sender. Sender does not waive / \ HTML MAILMorgan Stanley confidentiality or privilege, and use is prohibited. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Clearing sensitive in-memory data in perl
On Sat, Sep 17, 2005 at 11:40:26AM -0400, Victor Duchovni wrote: | On Sat, Sep 17, 2005 at 11:53:20AM +0100, Ben Laurie wrote: | | My view is that C is fine, but it needs a real library and programmers | who learn C need to learn to use the real library, with the bare-metal | C-library used only by library developers to bootstrap new safe | primitives. | | So wouldn't the world be a better place if we could all agree on a | single such library? Or at least, a single API. Like the STL is for C++. | | | Yes, absolutely, but who is going to do it? The glibc people? The openbsd people? I recall that for a while if you used gets, the linker would complain. I can't recall what platform this was on. BSDi, maybe? Adam - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: European country forbids its citizens from smiling for passport photos
From: William Allen Simpson [EMAIL PROTECTED] Do you really need to click on this link to know which one it is? http://cbs5.com/watercooler/watercooler_story_258152613.html Which one it is depends what the meaning of one is. Announced in multiple news sources last year: http://news.bbc.co.uk/1/hi/uk_politics/3541444.stm This page mentions international requirements. http://www.ukpa.gov.uk/press_050905.asp - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: European country forbids its citizens from smiling for passport photos
On Sat, Sep 17, 2005 at 10:52:48AM -0400, William Allen Simpson wrote: Do you really need to click on this link to know which one it is? U.K.? http://www.iht.com/articles/2005/09/12/news/travel13.php All of them? US and Canadia as well? http://cbs5.com/watercooler/watercooler_story_258152613.html I guess we should give neutral facial expressions for the photo, then smile (or frown) while in the airport We should violet-wand the smartcard pads. Or sever the antenna for the RFID. Or just use the dead tree one, and not reapply when it expires. Sounds like the technology (still) isn't ready for prime time. Not ready for 1984? One sure would hope so. -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07100, 11.36820http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
Re: European country forbids its citizens from smiling for passport photos
On 9/17/05, William Allen Simpson [EMAIL PROTECTED] wrote: Do you really need to click on this link to know which one it is? http://cbs5.com/watercooler/watercooler_story_258152613.html I guess we should give neutral facial expressions for the photo, then smile (or frown) while in the airport Sounds like the technology (still) isn't ready for prime time. And this is news why? http://www.pptc.gc.ca/passports/get_photo_specs_e.asp http://travel.state.gov/passport/guide/composition/composition_874.html -- GDB has a 'break' feature; why doesn't it have 'fix' too? - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Clearing sensitive in-memory data in perl
Victor Duchovni wrote: So wouldn't the world be a better place if we could all agree on a single such library? Or at least, a single API. Like the STL is for C++. Yes, absolutely, but who is going to do it? One could argue it has already been done. There exists a widely available, freely available, well-implemented example of something just like the STL for C++. It is called the STL for C++. a) Writing in C++ is easier than writing in C. b) Porting legacy C to C++ isn't rocket surgery. It can be done incrementally. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Clearing sensitive in-memory data in perl
[Moderator's note: forwarded on Jerry's behalf -- he's having mail problems.] | So wouldn't the world be a better place if we could all agree on a | single such library? Or at least, a single API. Like the STL is for C++. | | | | Yes, absolutely, but who is going to do it? | | One could argue it has already been done. | | There exists a widely available, freely available, well-implemented | example of something just like the STL for C++. It is called | the STL for C++. | | a) Writing in C++ is easier than writing in C. | | b) Porting legacy C to C++ isn't rocket surgery. It can be done | incrementally. And the STL is safer than C ... in what sense? STL iterators are modeled on C pointers - warts and all. An STL iterator can point to random memory just as easily as a C pointer. An indexing operation into an STL vector or similar data structure is subject to exactly as much range checking as a C indexing operation. Yes, there exist implementations of the STL that check such things - just as there exist implementations of C that check such things. None appear to be widely used. And, of course, while no standard *forbids* such checks, none *require* them, so (a) availability is spotty; (b) compilers typically contain no optimizations aimed at making such things efficient. RISKS had a large number of messages on this topic back in 2002. I wrote one long commentary (in RISKS 21.85 - see http://catless.ncl.ac.uk/Risks/21.85 for one on-line source) that I stand by to this day. Very little has changed. (Actually, there has been a *bit* of improvement: Microsoft submitted a proposal for a set of new string - and related - functions for standardization in the C library. They differ from the classic functions in always having an explicit output buffer length. Personally, I find the particular API typical of Microsoft - butt-ugly and a pain to use - and I *think* that the standards groups may be re-working them. But one way or another, after all these years, we may eventually have safe alternatives - once we work throught the standardization process and get the stuff out there (I'd guess another 2 years at least before you can safely assume that it'll be available). -- Jerry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Clearing sensitive in-memory data in perl
Adam Shostack wrote: On Sat, Sep 17, 2005 at 11:40:26AM -0400, Victor Duchovni wrote: | On Sat, Sep 17, 2005 at 11:53:20AM +0100, Ben Laurie wrote: | | My view is that C is fine, but it needs a real library and programmers | who learn C need to learn to use the real library, with the bare-metal | C-library used only by library developers to bootstrap new safe | primitives. | | So wouldn't the world be a better place if we could all agree on a | single such library? Or at least, a single API. Like the STL is for C++. | | | Yes, absolutely, but who is going to do it? The glibc people? The openbsd people? I recall that for a while if you used gets, the linker would complain. I can't recall what platform this was on. BSDi, maybe? gets is so not the problem. Using strings that _can_ overflow is the problem. That means wrapping the entire standard library. And, of course, the issue is that every other library in the universe uses C-style strings (etc.), so unless we can all agree on a better paradigm, we're screwed. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Clearing sensitive in-memory data in perl
On Sat, Sep 17, 2005 at 08:36:11PM +0100, Ben Laurie wrote: | Adam Shostack wrote: | On Sat, Sep 17, 2005 at 11:40:26AM -0400, Victor Duchovni wrote: | | On Sat, Sep 17, 2005 at 11:53:20AM +0100, Ben Laurie wrote: | | | | My view is that C is fine, but it needs a real library and programmers | | who learn C need to learn to use the real library, with the bare-metal | | C-library used only by library developers to bootstrap new safe | | primitives. | | | | So wouldn't the world be a better place if we could all agree on a | | single such library? Or at least, a single API. Like the STL is for | C++. | | | | | | Yes, absolutely, but who is going to do it? | | The glibc people? The openbsd people? | | I recall that for a while if you used gets, the linker would | complain. I can't recall what platform this was on. BSDi, maybe? | | gets is so not the problem. Using strings that _can_ overflow is the | problem. That means wrapping the entire standard library. | | And, of course, the issue is that every other library in the universe | uses C-style strings (etc.), so unless we can all agree on a better | paradigm, we're screwed. I didn't mean to imply that gets was the issue, only that when your linker laughed at you for trying to use a function, it was an encouragement to move to other functions. That is it possible to get people to move, when there's something to move to. Adam - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Clearing sensitive in-memory data in perl
Ben Laurie wrote: gets is so not the problem. Using strings that _can_ overflow is the problem. That means wrapping the entire standard library. And, of course, the issue is that every other library in the universe uses C-style strings (etc.), so unless we can all agree on a better paradigm, we're screwed. note that various infrastructures ... have made the length field an integral characteristic of nearly every piece of storage and that automatic use the length values an integral piece of every operation; extended from the lowest level interrupt handlers and device drivers ... up thru the most complex application code. it isn't just a characteristic of the high level application libraries ... but nearly every aspect of the operation environment. these length-based paradigms aren't only limited to programming languages (other than C) ... but can also be found in infrastructures that are pure assembler code. the other way of viewing the string issue is that the length isn't explicit ... the default c-based length paradigm is implicit based on the pattern of data in a buffer ... which tends to create length related vulnerabilities from simple data manipulation operations (you might generalize this as a dual-use vulnerability). this is further compounded when there is a field/buffer that is empty and doesn't yet have any data to establish an implicit data-pattern defined length. explicitly separating the length attribute from any data pattern characteristic would make the infrastructure less vulnerable to length mistakes resulting from simple data manipulation operations. it would also enable a single, consistant length paradigm for both field/buffers that contain data patterns and field/buffers that are empty and don't contain data patterns. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: European country forbids its citizens from smiling for passport photos
New Zealand did this earlier this year, as part of giving in to pressure from the US to have passports with biometric information. Here is a press release of last June from the NZ Green Party's Human Rights spokesperson. A quote from it Most people arriving in our fair land have smiles on their faces and there is nothing wrong with having passport photos to match http://www.greens.org.nz/searchdocs/PR8903.html -- Sidney Markowitz http://www.sidney.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Clearing sensitive in-memory data in perl
On 2005-09-17, Jerrold Leichter wrote (without retaining attributions): So wouldn't the world be a better place if we could all agree on a single such library? Or at least, a single API. Like the STL is for C++. Yes, absolutely, but who is going to do it? One could argue it has already been done. It (the creation of such a library) has been done many times; admittedly, widespread adoption has not happened at all. There exists a widely available, freely available, well-implemented example of something just like the STL for C++. It is called the STL for C++. a) Writing in C++ is easier than writing in C. Only for people who find it easier to use a huge clunky tool they will never fully know than a clean simple language which can be used to write completely reliable software. Of course, C's simplicity is its danger: any idiot who can spend a few hours with a C for Dummies kind of book can imagine that he's competent to write in C. As with any sharp tool, careful use is mandatory to avoid nasty cuts; thorough understanding is needed to ensure safe handling. We don't expect people to fly commercial aircraft without taking the time to become suitably skilled. We don't expect people to start doing brain surgery without having appropriate training. Software is complex stuff; it takes time to acquire skills with it. For those with the skills, C is an excellent tool. It's not perfect, but it's the best thing we have and it's well able to do the things we ask of it. The problem is bad programmers. b) Porting legacy C to C++ isn't rocket surgery. It can be done incrementally. And the STL is safer than C ... in what sense? STL iterators are modeled on C pointers - warts and all. An STL iterator can point to random memory just as easily as a C pointer. An indexing operation into an STL vector or similar data structure is subject to exactly as much range checking as a C indexing operation. Yes, there exist implementations of the STL that check such things - just as there exist implementations of C that check such things. None appear to be widely used. And, of course, while no standard *forbids* such checks, none *require* them, so (a) availability is spotty; (b) compilers typically contain no optimizations aimed at making such things efficient. Agreed, the STL (and C++) is no answer. RISKS had a large number of messages on this topic back in 2002. I wrote one long commentary (in RISKS 21.85 - see http://catless.ncl.ac.uk/Risks/21.85 for one on-line source) that I stand by to this day. Very little has changed. While you make some valid points in that article, I take issue with much of it. For instance, you cite [a] large body of code that provides bad examples as one of the big faults with C. This is just not a valid argument. (Yes it's true: there is such a body of code, but it's not an argument.) The classic book of examples of bad programming, The Elements of Programming Style by Kernighan and Plauger, dates back to the days before C. Its examples are in Fortran and PL/1. It is full of the same kind of blunders we are talking about here. It's not the language, it's the programmers who are at fault. The only reason that we see much in C is that, for the past 25 years, most widely-seen software has been written in C. (Actually, there has been a *bit* of improvement: Microsoft submitted a proposal for a set of new string - and related - functions for standardization in the C library. They differ from the classic functions in always having an explicit output buffer length. Personally, I find the particular API typical of Microsoft - butt-ugly and a pain to use - and I *think* that the standards groups may be re-working them. But one way or another, after all these years, we may eventually have safe alternatives - once we work throught the standardization process and get the stuff out there (I'd guess another 2 years at least before you can safely assume that it'll be available). I haven't followed any news about that. Anything that comes out of Microsoft won't be worth considering -- nothing from there has been good in the past, so there's no reason to think that might change. More to the point, it takes many years before stuff like that becomes widely available (and therefore usable). We don't need new tools; we just to learn to use the ones we have effectively. The comments you make about seat belt and air bags don't make much sense either. Their purpose is to save our lives after we have made a potentially fatal mistake. After all, there's a big mess to clean up when those things are used, so it's not like we want them to play an active part. This is also a question of culture. Everybody thinks they have the right to drive but no responsibility to learn how to do it well. So, since bad driving causes so many deaths, governments mandate all sorts of after-the-accident safety gadgets. If they mandated proper skill and attitude
Re: Clearing sensitive in-memory data in perl
-- Ben Laurie [EMAIL PROTECTED] And, of course, the issue is that every other library in the universe uses C-style strings (etc.), so unless we can all agree on a better paradigm, we're screwed. We have a better paradigm: C++ Use const zero terminated strings where possible, use STL strings where they must be non const. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG nsfA32EGEKM0cU+MepqW0siOwFXqhO6L4ObDt/5P 4n7mr1z57RP4q1W6q39DjzRerUpSJz4w3SYQPtVCh - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: ECC patents?
I'm not sure what you're trying to demonstrate here. From the fact that NSA chose to license a few curves, we can definitely deduce that they want to use those curves. You deduce from the fact that they didn't license other curves that there is no patent on those curves, but you could equally well deduce that the curves they did license are good enough and they don't need to pay extra money to license on the other curves. William -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of James A. Donald Sent: Friday, September 16, 2005 11:53 PM To: cryptography@metzdowd.com Subject: RE: ECC patents? -- Whyte, William [EMAIL PROTECTED] $25MM figure: http://lists.jammed.com/ISN/2003/10/0097.html I stand corrected. However as was pointed out previously: : : Further, the license would be limited to only : : prime field curves where the prime was : : greater than 2255. On the NIST list of curves : : 3 out of the 15 fit this field of use: the : : prime field curves with primes of 256 bits, : : 384 bits and 521 bits. Of the NIST list of fifteen, nine are 256 bits or longer. Presumably, if NSA thought certicom had a case, they would have licensed at least the other six NIST curves as well, and most likely the other twelve. The three curves that are licensed look different from the other twelve, though I have no idea of the significance of this, if any. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG ZKrN4sA2qyTNIC90h3U/8Er848IPFGfUOQyBxm8h 4xlZJBIqZwgUkOyqgxTzTBcauENSjU46x6oDgn2X4 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
