Re: crypto for the average programmer
Jack Lloyd wrote: On Fri, Dec 16, 2005 at 05:41:48PM +, Ben Laurie wrote: No, OpenSSL is self-contained. There is, IIRC, an engine that uses GMP if you want, but its entirely optional; OpenSSL has its own bignum implementation that's just as good. Last I checked, public key operations in OpenSSL were significantly faster using the GNU MP engine - so just as good is perhaps not entirely accurate. OpenSSL's BN library is still very fast compared to many other MPI implementations, of course. Apparently this rather depends on platform and compiler options. I am reliably informed that GMP is not always faster. For those that really care it'd be cool if someone did a careful comparison. It would also be interesting to know why they differ. 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: crypto for the average programmer
On Tue, Dec 27, 2005 at 02:28:07PM +, Ben Laurie wrote: Apparently this rather depends on platform and compiler options. I am reliably informed that GMP is not always faster. For those that really care it'd be cool if someone did a careful comparison. It would also be interesting to know why they differ. Thank you for the correction. My statement was primarily on the basis of some benchmarks I ran at the time I wrote some backend code in Botan to dump crypto operations to GNU MP and/or OpenSSL when available, and at the time GNU MP outperformed OpenSSL by a fairly large margin on x86 and Alpha machines (up to 50% on large RSA private key operations; as the keys got smaller the performance difference reduced, down to basically nothing at 512 bit keys). However I have since checked my changelogs and realized I must have run those tests almost two years ago now (which surprised me a bit!), so I'm sure those results are not particularly reflective of current performance. I'll have to revisit this and see how things stack up these days on the platforms I care about. -Jack - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: crypto for the average programmer
In message [EMAIL PROTECTED] on Sun, 18 Dec 2005 21:56:11 -0600, Travis H. [EMAIL PROTECTED] said: solinym Anytime someone wants to rewrite a C library in a language solinym less prone to buffer overflows, I'm totally for it. Some say solinym that it's not the library, it's the programmer, but I think solinym that denies human factors. C simply requires too much solinym machinery on top of it to use it securely. [...] solinym And yet cryptographers continue to write in C. C has three really strong points: - portability. It's one of the most wide-spread and portable compiled languages that I know of. - speed. Most languages with the same level of portability as C that I know of are interpreted. They will probably never get to the level of speed you can get with C. - simple or compatible ABI. C++ could be a good candidate if handled properly (yeah, yeah, I know), but I've yet to see that the ABI used by different compilers on the same platform not differ so much. Most all, I'm thinking of name mangling (uhm, not really sure if that an ABI issue or not :-)). As soon as there's a more secure language that fills those criteria, I see not reason why you'd want to stay with C. In the mean time, we'll probably have to keep on living with its' defficiencies (I do agree with you about those). Cheers, Richard - Please consider sponsoring my work on free software. See http://www.free.lp.se/sponsoring.html for details. -- Richard Levitte [EMAIL PROTECTED] http://richard.levitte.org/ When I became a man I put away childish things, including the fear of childishness and the desire to be very grown up. -- C.S. Lewis - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: crypto for the average programmer
On 12/19/05, Richard Levitte - VMS Whacker [EMAIL PROTECTED] wrote: C has three really strong points: - portability. It's one of the most wide-spread and portable compiled languages that I know of. I beg your pardon? If I want to store 128 bits of information, and access the 8 most significant bits, what portable data type would I use? :) The only way C is even remotely portable is with 30 years of #include and typedef machinery, and POSIX, and many other standards. - speed. Most languages with the same level of portability as C that I know of are interpreted. They will probably never get to the level of speed you can get with C. The old joke is that C combines the speed and power of assembly language with the portability of assembly language. Ocaml can outperform C in some cases. Java is within an order of magnitude- The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: crypto for the average programmer
In message [EMAIL PROTECTED] on Mon, 19 Dec 2005 01:19:37 -0600, Travis H. [EMAIL PROTECTED] said: solinym On 12/19/05, Richard Levitte - VMS Whacker [EMAIL PROTECTED] wrote: solinym C has three really strong points: solinym solinym - portability. It's one of the most wide-spread and solinym portable compiled languages that I know of. solinym solinym I beg your pardon? If I want to store 128 bits of solinym information, and access the 8 most significant bits, what solinym portable data type would I use? :) unsigned char foo[8]; (no, it isn't fool proof, but close enough after 1 second of thought). solinym The only way C is even remotely portable is with 30 years of solinym #include and typedef machinery, and POSIX, and many other solinym standards. You tell me what other language combines the wide spread (which is important for portability) and speed of C. Maybe I should have mentioned availability as well... solinym - speed. Most languages with the same level of solinym portability as C that I know of are interpreted. They solinym will probably never get to the level of speed you can solinym get with C. solinym solinym The old joke is that C combines the speed and power of solinym assembly language with the portability of assembly language. Yeah, I've heard it before, and it's a lot of bull, at least the part about portability. I'd like to see you run an assembly program for a 68K on a VAX, or a VAX MACRO program on anything else, or... Oh, and for fairly modern stuff, try porting assembler between, say, an Alpha and a Pentium... Yeah, you probably got it by now. solinym Ocaml can outperform C in some cases. Java is within an solinym order of magnitude. Show me that ocaml is available on all current major platforms, and I'll start looking at it. And please, look outside the Unix family sandbox. For me, VMS is one of the must-be platforms. solinym I mean, technically, the python interpreter is written in C, solinym right? So technically I am using C code when I write a solinym python script. And the C is implemented in assembler, which solinym are implemented as microinstructions which are implemented as solinym gates. The point is, pick good expressive primitives, then solinym analyze and re-use that low level stuff to write things at a solinym higher level. Minimize the amount you do in an unsafe way. For some things, I'd agree. It all depends on what we're talking about, and from the subject, I'd gather we're mostly talking about crypto algorithms, which is fairly low level stuff in the security hierarchy. I dunno about you, but it seems like most people are a bit obsessed with speed at that level, like how many AES operations you can do per second. Unfortunately, the higher you go, the more complex your operations become, and if we're talking interpreted languages, there will always be the cost of interpretation, dispatching into the underlying C routines, conversion of results, and so on. I can't see any way to get around that part. Cheers, Richard - Please consider sponsoring my work on free software. See http://www.free.lp.se/sponsoring.html for details. -- Richard Levitte [EMAIL PROTECTED] http://richard.levitte.org/ When I became a man I put away childish things, including the fear of childishness and the desire to be very grown up. -- C.S. Lewis - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: crypto for the average programmer
On 12/19/05, Richard Levitte - VMS Whacker [EMAIL PROTECTED] wrote: unsigned char foo[8]; (no, it isn't fool proof, but close enough after 1 second of thought). I think C guarantees that a char is a byte, but exactly how wide that is is processor-dependent. IIRC, some of the machines it was developed on had less than 8 bits per byte, but I could be wrong. Surely a smaller byte is antiquated, but a wider char is certainly conceivable. Things don't really get messy until you start converting types or communicating them to another machine. At that point, you really want to know if your int is 32 bits or 64, big or little endian, etc. OTOH, if C was truly as portable as is claimed, GNU autoconf wouldn't exist. Scripts are fairly portable; I can run bash scripts in cygwin, I can run perl scripts using activeperl. None have required modification so far, though some use libraries (modules) that aren't available on the target. I realized halfway through this that I was thinking of applications that use crypto, and not crypto algorithms per se. But pretty much we sound like we're in agreement on most things. -- http://www.lightconsulting.com/~travis/ -- P=NP if (P=0 or N=1) My love for mathematics is like 1/x as x approaches 0. GPG fingerprint: 50A1 15C5 A9DE 23B9 ED98 C93E 38E9 204A 94C2 641B - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: crypto for the average programmer
In message [EMAIL PROTECTED] on Mon, 19 Dec 2005 03:12:16 -0600, Travis H. [EMAIL PROTECTED] said: solinym On 12/19/05, Richard Levitte - VMS Whacker [EMAIL PROTECTED] wrote: solinym unsigned char foo[8]; solinym solinym (no, it isn't fool proof, but close enough after 1 second solinym of thought). solinym solinym I think C guarantees that a char is a byte, but exactly how solinym wide that is is processor-dependent. IIRC, some of the solinym machines it was developed on had less than 8 bits per byte, solinym but I could be wrong. Nope, you're right. For example, on old PDP-10 and DEC-20, you'd have 5 7-bit chars in each 36-bit int. Not entirely sure how unsigned chars were implemented, though... solinym Surely a smaller byte is antiquated, but a wider char is solinym certainly conceivable. Yup, I realised all that, hence it isn't fool proof. solinym OTOH, if C was truly as portable as is claimed, GNU autoconf solinym wouldn't exist. It's true that the proliferation of incompatible header standards and platform specific libraries have made things harder, as well as the differing size and characteristics of some of the types. Still, because there's a way to build conditional code in a way that works on all platforms, I still think it's among the more portable languages. Not saying it's perfect, far from it, but I've yet to see another language that has similar characteristics. solinym Scripts are fairly portable; I can run bash scripts in solinym cygwin, I can run perl scripts using activeperl. None have solinym required modification so far, Yeah, for crypto stuff, I must say that I don't find bash or perl to be strong candidates, at least at the lowest level. solinym though some use libraries (modules) that aren't available solinym on the target. Uhmm, isn't that what you'd use GNU autoconf for? In my experience, GNU autoconf is mostly used to figure out what the environment is composed of, what libraries are available and things like that. solinym I realized halfway through this that I was thinking of solinym applications that use crypto, and not crypto algorithms per solinym se. Oh... when you started this thread with talking about rewriting C libraries to something less error prone, I didn't imagine you were talking about the higher levels of functionality. I believe a lot of languages have a layer to interface with the lower level C libraries, and I know that at least Perl, Python and Ocaml have interfaces to the crypto algorithms in OpenSSL. solinym But pretty much we sound like we're in agreement on most solinym things. Well, at least that C sucks :-). Cheers, Richard - Please consider sponsoring my work on free software. See http://www.free.lp.se/sponsoring.html for details. -- Richard Levitte [EMAIL PROTECTED] http://richard.levitte.org/ When I became a man I put away childish things, including the fear of childishness and the desire to be very grown up. -- C.S. Lewis - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: crypto for the average programmer
At 03:34 PM 12/14/2005, [EMAIL PROTECTED] wrote: An application programmer who is using PKCS1 doesn't even need to know the small amount of ASN.1 in the spec... libraries that implement RSA PKCS1 take care of the ASN.1 for the programmer. This is in fact one reason that ASN.1 exploits have been so wide-ranging when they've happened. ASN.1 is a horrendously ugly mess, even uglier than PGP, so almost everybody uses an existing library instead of rolling their own or writing a new library for other users. Major bugs aren't discovered often, but everybody's pretty much using the same C code, whether for SNMP or X.509 or whatever. I don't know how many of the Java et al. versions have rewritten it natively as opposed to importing C libraries, which is probably more convenient. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: crypto for the average programmer
Anytime someone wants to rewrite a C library in a language less prone to buffer overflows, I'm totally for it. Some say that it's not the library, it's the programmer, but I think that denies human factors. C simply requires too much machinery on top of it to use it securely. It is possible to write secure C code, much as it is possible to write portable C code, but it requires discipline, and C makes it marginally harder to use new constructs than native ones. C's string libraries in particular are so complex to use securely that OpenBSD rewrote them. And unlike portability, one cannot create a test that assures that you have coded securely. And yet cryptographers continue to write in C. HHLs have their problems; in an interpreted language with immutable strings, it may be hard to overwrite a crypto key. However, these kinds of problems do not account for 50% of the current vulnerabilities the way buffer overflows do. -- http://www.lightconsulting.com/~travis/ -- P=NP if (P=0 or N=1) My love for mathematics is like 1/x as x approaches 0. GPG fingerprint: 50A1 15C5 A9DE 23B9 ED98 C93E 38E9 204A 94C2 641B - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: crypto for the average programmer
On Fri, Dec 16, 2005 at 05:41:48PM +, Ben Laurie wrote: No, OpenSSL is self-contained. There is, IIRC, an engine that uses GMP if you want, but its entirely optional; OpenSSL has its own bignum implementation that's just as good. Last I checked, public key operations in OpenSSL were significantly faster using the GNU MP engine - so just as good is perhaps not entirely accurate. OpenSSL's BN library is still very fast compared to many other MPI implementations, of course. -Jack - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: crypto for the average programmer
[EMAIL PROTECTED] wrote: | | My question is, what is the layperson supposed to do, if they must use | | crypto and can't use an off-the-shelf product? | | | | When would that be the case? | | | | The only defensible situations I can think of in which a | | non-crypto-specialist programmer would need to write crypto routines | | would be an uncommon OS or hardware, or a new or rare programming | | language which doesn't have libraries available from SourceForge etc. | | Or maybe implementing an algorithm that's new enough it doesn't have a | | decent free implementation, but I'm not sure such an algorithm should | | be used in production code. | I can tell you a situation that applied in one system I worked on: You | could | go with SSL, which gets you into GPL'ed code, not to mention the known | | Eh? OpenSSL is BSD, not GPL. When I last looked at this, OpenSSL was BSD, but it required some libraries (GMP?) that were GPL. No, OpenSSL is self-contained. There is, IIRC, an engine that uses GMP if you want, but its entirely optional; OpenSSL has its own bignum implementation that's just as good. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: crypto for the average programmer
Travis H. [EMAIL PROTECTED] writes: In Peter Gutmann's godzilla cryptography tutorial, he has some really good (though terse) advice on subtle gotchas in using DH/RSA/Elgamal. I learned a few no-nos, such as not sending the same message to 3 seperate users in RSA (if using 3 as an encryption exponent). I should point out that what's in the tutorial isn't an exhaustive list of potential pitfalls, it simply contains examples of some of the easiest-to- explain ones. The reason for adding that section was that I've seen a number of cases of people using raw PKC ops (e.g. raw, unpadded RSA) because their boss told them Use RSA encryption and their crypto toolkit provides an rsaEncrypt() function, the result being that they encrypt a 10MB file with RSA in ECB mode. Java is the main offender here, they make it pretty trivial to do this even though it makes no sense, so people who are told to encrypt this with RSA end up using the RSA-ECB that their tools give them. My question is, what is the layperson supposed to do, if they must use crypto and can't use an off-the-shelf product? Is there any site tracking such gotchas as they show up in the literature? I don't know if there's any site tracking this, but (as the tutorial says) you can either go with PKCS #1 (the de facto standard, easy to implement and widely used) or if you want to put in the effort of tracking things through the literature to see which one is currently in fashion, take your pick of OAEP, RSA-PSS, Simple RSA, and so on ad nauseum. The P1363 work tracks progress in this area pretty closely, although you'll need some sort of P1363- to-english phrasebook to figure out what they're saying. Are there APIs written specifically so that a crypto-naive programmer can safely use them? Uhh, do you want a non-off-the-shelf product or an off-the-shelf product? If off-the-shelf is OK, grab any crypto toolkit that handles this for you and use that, you know that if it's used in any standard protocol and interoperates with a pile of other software then there's a good chance they've got it right. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: crypto for the average programmer
On 12/14/05, Peter Gutmann [EMAIL PROTECTED] wrote: I don't know if there's any site tracking this, but (as the tutorial says) you can either go with PKCS #1 (the de facto standard, easy to implement and widely used) ... Actually, I'm embarassed to admit this but I've seen PKCS before but never with enough context to know what it was; I thought it was some kind of RSA proprietary mumbo-jumbo. But, oh dear, it involves ASN.1. That rules out use by the layperson. I've run into ASN.1 before with regard to SNMP, and it struck me as infinitely more complex than anything I'd ever need to query packet counts on my router. MIBs, subtype constraints, multiple sets of encoding rules, schemata? Hopeless. The descriptions of ASN.1 I've seen are more complicated than any cryptographic primitive I've ever run across. I'd trust an ASN.1 codec library about as much as I'd trust a DCE/RPC codec, give or take an order of magnitude. I'm not trying to be excessively curmudgeonly today, but I have to note that the top google hit for ASN.1 has a list of myths about ASN.1, of which the last two are true, a tutorial that begins with me writing an ASN.1 specification with no guidance or introduction whatsoever, and defines ASN.1 as a formalism for the specification of abstract data types. Oh, well that clears it up. Does it help me adopt new paradigms of data representation in a dynamic, fast-paced environment? And with that, I'm out. :-P -- http://www.lightconsulting.com/~travis/ -- P=NP if (P=0 or N=1) My love for mathematics is like 1/x as x approaches 0. GPG fingerprint: 50A1 15C5 A9DE 23B9 ED98 C93E 38E9 204A 94C2 641B - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: crypto for the average programmer
On 12/14/05, Peter Gutmann [EMAIL PROTECTED] wrote: I don't know if there's any site tracking this, but (as the tutorial says) you can either go with PKCS #1 (the de facto standard, easy to implement and widely used) ... Actually, I'm embarassed to admit this but I've seen PKCS before but never with enough context to know what it was; I thought it was some kind of RSA proprietary mumbo-jumbo. But, oh dear, it involves ASN.1. That rules out use by the layperson. I've run into ASN.1 before with regard to SNMP, and it struck me as infinitely more complex than anything I'd ever need to query packet counts on my router. Have a look at PKCS#1. There's hardly any ASN.1 in it at all and the structures are relatively simple. There's also a PKCS examples document that talks you through it. William - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: crypto for the average programmer
My question is, what is the layperson supposed to do, if they must use crypto and can't use an off-the-shelf product? When would that be the case? The only defensible situations I can think of in which a non-crypto-specialist programmer would need to write crypto routines would be an uncommon OS or hardware, or a new or rare programming language which doesn't have libraries available from SourceForge etc. Or maybe implementing an algorithm that's new enough it doesn't have a decent free implementation, but I'm not sure such an algorithm should be used in production code. Indefensible situations include the programmer wanting to write his own crypto because it's cool or because he just knows he can do better than all the specialists (in which case he's too arrogant or ignorant to benefit from a common gotchas list) or the manager telling the programmer to implement it himself for some bad reason (in which case the programmer should explain why that's a bad idea). -- Oooh, so Mother Nature needs a favor?! Well maybe she should have thought of that when she was besetting us with droughts and floods and poison monkeys! Nature started the fight for survival, and now she wants to quit because she's losing. Well I say, hard cheese. -- Montgomery Burns - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: crypto for the average programmer
In Peter Gutmann's godzilla cryptography tutorial, he has some really good (though terse) advice on subtle gotchas in using DH/RSA/Elgamal. I learned a few no-nos, such as not sending the same message to 3 seperate users in RSA (if using 3 as an encryption exponent). My question is, what is the layperson supposed to do, if they must use crypto and can't use an off-the-shelf product? Check the standards. The RSA PKCS#1 standard, which are free, describe how to do RSA securely and summarize known security results. http://www.rsasecurity.com/rsalabs/node.asp?id=2124. Don't use PKCS#3-style Diffie Hellman; it's been superseded by the versions in ASC X9.42 and IEEE Std 1363-2000. The Standards for Efficient Cryptography Group (www.secg.org) publishes SEC1, which describes how to do Elliptic curve algorithms securely. The standard is free to download, but note that some techniques in it have licensing requirements. NIST, in its series of FIPS standards and Special Publications, has defined federal standards for digital signatures and modes of operation for symmetric ciphers, and is moving towards standardizing key exchange mechanisms based on public key algorithms. Those standards are also free, though they sometimes reference non-free standards. Other standards groups, such as the IEEE P1363 Working Group (which I chair -- http://grouper.ieee.org/groups/1363/) and the ASC X9F1 working group for cryptographic techniques for the financial services industry, publish (for purchase) standards for secure use of other public-key algorithms. 1363 is currently working on - Lattice-based cryptography, such as NTRU (who I work for) - Password-based public key techniques such as SPEKE, SRP, etc - A revision of the 1363-2000 standard. A lot of the documents relevant to these projects are available for free off the site. X9 is working on a wider range of projects, but your company has to be an X9 member for you to access them. Is there any site tracking such gotchas as they show up in the literature? Rather than tracking gotchas minute-by-minute it's probably best to use existing standards. Cheers, William - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: crypto for the average programmer
NIST, in its series of FIPS standards and Special Publications, has defined federal standards for digital signatures and modes of operation for symmetric ciphers, and is moving towards standardizing key exchange mechanisms based on public key algorithms. Those standards are also free, though they sometimes reference non-free standards. Sorry, meant to include links for these: Overall home page: http://csrc.nist.gov/focus_areas.html#csa FIPS: http://csrc.nist.gov/publications/fips/index.html Special Publications: http://csrc.nist.gov/publications/nistpubs/ Wiliam - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: crypto for the average programmer
On Mon, 12 Dec 2005, Travis H. wrote: In Peter Gutmann's godzilla cryptography tutorial, he has some really good (though terse) advice on subtle gotchas in using DH/RSA/Elgamal. I learned a few no-nos, such as not sending the same message to 3 seperate users in RSA (if using 3 as an encryption exponent). Probably you have misunderstood it: if you do it correctly (e.g., use some standard method like RSAES-OAEP or even RSAES-PKCS1-v1_5) you can send the same message to 3 (or whatever) separate users without any bad consequences. The problem appears if you use some non-standard method, e.g., plain RSA (c = m^e \pmod n). My question is, what is the layperson supposed to do, if they must use crypto and can't use an off-the-shelf product? This is quite simple: get some respected standard (see, e.g., NIST http://csrc.nist.gov/CryptoToolkit/ or PKCS http://www.rsasecurity.com/rsalabs/node.asp?id=2124) and implement it exactly. Interoperability is a bonus :-) -- Regards, ASK - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: crypto for the average programmer
Date sent: Mon, 12 Dec 2005 00:41:13 -0600 From: Travis H. [EMAIL PROTECTED] To: cryptography@metzdowd.com Subject:crypto for the average programmer In Peter Gutmann's godzilla cryptography tutorial, he has some really good (though terse) advice on subtle gotchas in using DH/RSA/Elgamal. I learned a few no-nos, such as not sending the same message to 3 seperate users in RSA (if using 3 as an encryption exponent). My question is, what is the layperson supposed to do, if they must use crypto and can't use an off-the-shelf product? Is there any site tracking such gotchas as they show up in the literature? Are there APIs written specifically so that a crypto-naive programmer can safely use them? It seems to me that if the only thing you use public key encryption for is to encrypt a single use randomly chosen symmetric key, and integrity bits for that key, and if you then use that symmetric key once and only once, to encrypt a message that already contains integrity checking and a unique random number, you don't need to worry about those issues. Of course those issues reappear when using public keys for signature algorithms - so don't invent your own signature protocol. Signatures are hard. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: crypto for the average programmer
-- From: Whyte, William [EMAIL PROTECTED] Check the standards. The RSA PKCS#1 standard, which are free, describe how to do RSA securely and summarize known security results. http://www.rsasecurity.com/rsalabs/node.asp?id=2124. Don't use PKCS#3-style Diffie Hellman; it's been superseded by the versions in ASC X9.42 and IEEE Std 1363-2000. The Standards for Efficient Cryptography Group (www.secg.org) publishes SEC1, which describes how to do Elliptic curve algorithms securely. The standard is free to download, but note that some techniques in it have licensing requirements. NIST, in its series of FIPS standards and Special Publications, has defined federal standards for digital signatures and modes of operation for symmetric ciphers, and is moving towards standardizing key exchange mechanisms based on public key algorithms. Those standards are also free, though they sometimes reference non-free standards. Of course most of this has already been incorporated in standard crypto libraries, such as CryptoPP, and does not need to be rewritten. Be warned, however, that if you faithfully follow a standard without comprehending why the standard is the way that it is, you will probably screw it up, because you will not really understand what faithfullness is. In practice, it is frequently necessary to roll your own damned standards, and in practice, people who roll their own damned standard frequently get them wrong. For example SSH had to be SSH, it could not be SSL, and the first version of SSH was, predictably, wrong. Similarly the first version of Wifi used WEP, which contained errors that should have been spotted, but were not. They had to roll their own, because they needed to solve a particular problem which was not the same as the problems that other standards solve. You should, however, never roll your own damned standard without good reason. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG TXXgVeLZjViyf6+f7NQt7WCs7MzxO/j25GYLXcEg 4js14nleizkni3mC38n+4rk2r07+4mylYuP2+UnlI - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: crypto for the average programmer
On Mon, 12 Dec 2005, Steve Furlong wrote: | My question is, what is the layperson supposed to do, if they must use | crypto and can't use an off-the-shelf product? | | When would that be the case? | | The only defensible situations I can think of in which a | non-crypto-specialist programmer would need to write crypto routines | would be an uncommon OS or hardware, or a new or rare programming | language which doesn't have libraries available from SourceForge etc. | Or maybe implementing an algorithm that's new enough it doesn't have a | decent free implementation, but I'm not sure such an algorithm should | be used in production code. I can tell you a situation that applied in one system I worked on: You could go with SSL, which gets you into GPL'ed code, not to mention the known complexities of using the SSL libraries correctly (steep learning curve); or we could go commercial code that had fairly steep license fees. The decision was to use off-the-shelf where completely unencumbered (e.g., Gladman's AES implementation), build the rest ourselves. BTW, there are other issues with SSL. We needed to fit this implementation in to an already-running system with minimal effect - but try to get people to use it. Having to get certificates for SSL was a big hurdle. Even creating self-signed certs was a hassle. The existing code ran directly over TCP, and assumed a byte stream. SSL is record-oriented. This shows up, for example, when your 1-byte ACK (of which we send many) turns into a 32-byte block (or even larger). We weren't interested in complete security - we just needed to raise the level considerably. Given the nature of the application, message authentication was not *that* big a deal - it could be put off. SSL is a fine protocol, and on theoretical terms, yes, you probably want everything it provides. But in practice it's too much. BTW, there are some interesting social issues. Before we implemented our own crypto layer, we recommended people go through ssh tunnels. The product was set up to allow that. I made the argument Do you really want us to provide your crypto? We're not crypto experts. But this was perceived as clunky, complicated ... it didn't make it look as if the *product*. Those factors were ultimately seen as more important than the very highest level of security. You can *still* use ssh, of course (In fact, I was in a discussion with a military contractor who wanted to use the product. The question came up of exactly how our crypto worked, whether it would be approvable for their application, etc. My comment was: Isn't NSA providing you guys with encrypted links anyway? Answer - sure, you're right; we don't need to do application-level encryption. If IPSEC were actually out there, all sorts of nasty issues would just magically go away.) -- Jerry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
