Re: Fwd: Protection mail at rest
On 2008-06-02, Adam Aviv wrote: I recently implemented SSARES directly in python and also added parallelism to the searching. We can now search the a large inbox (1000+) messages in about 2-4 minutes. Not to rain on your parade, but 1,000 messages is *not* a large inbox and 2 to 4 minutes is a very long time to wait. You'd need to make this two orders of magnitude faster before it would have a hope of being interesting. (And for me, it would have to be at least four orders of magnitude faster before I could consider it to be useful.) Greg - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: More info in my AES128-CBC question
On 2007-04-21, David Wagner wrote: If you're sick and you go to a doctor, do you tell the doctor you'd better come up with some very clear arguments if you want me to follow your advice? Do you tell your doctor you'd better build a strong case before I will listen to you? I would hope not. That would be silly. Not at all. That would be smart. Blind deference to experts, in any field, is just plain stupid. Doctors are medical professionals with a great deal of training and expertise in the subject. They can speak with authority when it comes to your health. So why do people with no training in security think that they can freely ignore the advice of security professionals without any negative consequences? Asking the professionals to make a clear case is not the same as freely ignoring them. But blindly following those who speak with authority leads to all sorts of nonsensical outcomes. If we are consulting an expert, it behoves us to examine the expert's reasoning. If we are the experts, we should expect to have to explain ourselves to those who rely on us -- and we should volunteer those explanations rather than making people drag them out of us. Cheers, Greg - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: A note on vendor reaction speed to the e=3 problem
On 2006-09-28, Leichter, Jerry wrote: VMS has for years had a simple CHECKSUM command, which had a variant, CHECKSUM/IMAGE, applicable only to executable image files. It knew enough about the syntax of executables to skip over irrelevant metadata like link date and time. (The checksums computed weren't cryptographic - at least the last time I used it, many years ago. The command was created to use in patches to provide a quick verification that the file being patched was the right one.) I've always found it surprising that no one seems to have developed similar tools for Unix - with the Gnu libraries for portable access to object/ executable files, it could be done relatively easily. This is incorrect. Hundreds of people have developed such tools and use them regularly. I've never bothered to look for any published versions, because my own tool works for me, but I'd be surprised if there weren't any out there in the wild. Greg - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: NPR : E-Mail Encryption Rare in Everyday Use
On 2006-02-24, Peter Saint-Andre wrote: Personally I doubt that anything other than a small percentage of email will ever be signed, let alone encrypted (heck, most people on this list don't even sign their mail). That's at least partly because too many mailing lists either reject signed messages out of hand or, worse, have subscribers who use providers that reject signed messages and then spam you with their idiotic bounce messages. Keeping track of which lists allow signed email and which don't is impractical if you subscribe to hundreds of lists, so the simple thing is to tick the don't sign box on list messages. In this case, since Peter's message was signed, I know this list allows signatures. So I'll sign this message. But the signature will be of limited utility, as not one of the several email addresses on my signature is a match for the email address I am sending this from. Again, lists being what they are, I use a different address for most lists and my PGP key would become absurd if I added several hundred addresses to it. I personally would prefer to sign every email I send. I'd also prefer to encrypt all non-public messages. I am fully competent in the use of the current technology, but it turns out to be not practical to use. Greg pgp3qLCcQF5wT.pgp Description: PGP signature
Re: [Clips] Banks Seek Better Online-Security Tools
On 2005-12-02, [EMAIL PROTECTED] wrote: You know, I'd wonder how many people on this list use or have used online banking. To start the ball rolling, I have not and won't. I've been using it for me and my wife with 3 banks since they first offered it; I use it every week to pay all our bills and would not be without it. The benefits I have gained from not having to waste time doing things the old way have proved to be substantial and I get to notice and resolve the occasional error (always in the form of fraudulent debits to credit cards) much faster than in the old days when I had to wait for the monthly statements. It's probably not related to my use of online banking, but it has also been noticeable that fraudulent debits to our credit cards have dropped from about 5 per card per year five years ago to one such debit to the 6 cards we use in the past two years. I detest banks and have had many battles with them over various issues over the years, but I remain confident that my careful practices, meticulous record keeping and careful management of passwords will continue to give me the edge in any dispute with them. And the cost to me of any such disputes seems unlikely to be anything like the benefits I have gained from online banking. Greg - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Java: Helping the world build bigger idiots
On 2005-09-20, Jerrold Leichter wrote:
One thing to consider is that an idiom like this solves an annoying problem.
Consider a linear search through an array:
for (i = 0; i lim; i++)
{ if (a[i] == target)
{ do something
break;
}
}
/*
* Did we get here because we matched or because we
* failed to match?
*/
No, we got here because we didn't know basic C usage. Come on
people, please stop creating these fake illustrations.
A real C programmer would have known that, if i == lim, there
was no match. This is so trivial it beggars belief that it
needs to be pointed out in a forum like this.
Personally, I sometimes use:
for (i = 0; i lim; i++)
{ if (a[i] == target)
goto found;
}
This draws shock and horror from some code readers, but I don't care. :-)
Note how much it looks like the exception-based code.
It only draws gasps from people who don't know C. The goto that
is famously considered harmful is not spelled goto in C, but
rather longjmp; it's not used all that often and does need
careful handling. The C goto statement is purely a local goto
and scares nobody who has grown up.
Greg
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Clearing sensitive in-memory data in perl
On 2005-09-18, Ian G wrote: Greg Black wrote: The problem is bad programmers. No, the problem is good programmers. When K R wrote C in the early 70s K R did not write C, they wrote a book about C. R was the creator of the language, with some inspiration and collaboration from some others at Bell Labs, mainly Ken Thompson. For the history, see DMR's paper The Development of the C Language at http://cm.bell-labs.com/cm/cs/who/dmr/chist.html. Re the book, BWK wrote the descriptive part and DMR wrote the appendix that described the language. Not surprisingly, BWK's part has most of the real errors (as distinct from typos). , programming was a real heavy duty science, and K R were in a place which was one of the meccas of the art. They wrote a language for not only good programmers, but for great programmers. Dennis wrote C for Ken (and for his own amusement). It was adopted by other people at Bell when they saw how useful it was and escaped for the same reason. Their world is not the world we live in Indeed it's not. In particular, our world has bad guys and cheap, powerful hardware with no constraints on memory or particular needs for efficiency. If somebody like Ritchie sat down today to write a new language to replace C, then it would indeed be different and people with real work to do might even switch to it. But not one language that has appeared since C is as useful and every language that has appeared since then has had significant disadvantages in comparison. The only languages that strike me as being in any way comparable are the Lisp family -- but they are useless for system programming, and so people like me tend to stick to C since it can do everything. (Of course, I use other languages as well; but C is the basis of everything I do.) PS: if one is forced to use C, what is the best recommendation for string / array processing? One is never /forced/ to use C. One chooses the tools to best do the job. One day, I'll package up my string library, which would then be my recommendation. As it is now, it's used in quite a few places where I have consulted (since working with software teams almost always involves teaching them to use C effectively). The only string library that I'm aware of that's freely available is Dan Bernstein's stralloc[1] library and its array library[2] successor: [1] http://cr.yp.to/lib/stralloc.html [2] http://cr.yp.to/lib/array.html These both have disadvantages common to all DJB code: weird licensing, unreadable style, and somewhat fanatic admiration of his own work in preference to all other work. However, for somebody wanting some ideas for implementation of their own library, these might make a useful starting point. Bear in mind that, even though we are not all Ritchies, those of us who work with software can learn to use sharp tools if we take the time to do it and put in the work required. If that's really too much, then there are always buses that need drivers. Greg - 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
