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
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
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]
[ANNOUNCE] OpenSSL version 0.9.7i released
OpenSSL version 0.9.7i released === OpenSSL - The Open Source toolkit for SSL/TLS http://www.openssl.org/ OpenSSL 0.9.7h caused crashes when the shared libcrypto was upgraded. This release fixes that problem. For those who want or have to stay with the 0.9.7 series of OpenSSL instead of using the 0.9.8 series, we strongly recommend that you upgrade to OpenSSL 0.9.7h soon as possible. For a complete list of changes, please see http://www.openssl.org/source/exp/CHANGES. OpenSSL 0.9.7i is available for download via HTTP and FTP from the following master locations (you can find the various FTP mirrors under http://www.openssl.org/source/mirror.html): * http://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ The distribution file names are: * openssl-0.9.7i.tar.gz MD5 checksum: f69d82b206ff8bff9d0e721f97380b9e SHA1 checksum: 4c23925744d43272fa19615454da44e01465eb06 The checksums were calculated using the following commands: openssl md5 openssl-0.9.*.tar.gz openssl sha1 openssl-0.9.*.tar.gz Yours, The OpenSSL Project Team... Mark J. Cox Nils Larsch Ulf Möller Ralf S. Engelschall Ben Laurie Andy Polyakov Dr. Stephen Henson Richard Levitte Geoff Thorpe Lutz JänickeBodo Möller - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
[ANNOUNCE] OpenSSL 0.9.8 released
OpenSSL version 0.9.8 released == OpenSSL - The Open Source toolkit for SSL/TLS http://www.openssl.org/ The OpenSSL project team is pleased to announce the release of version 0.9.8 of our open source toolkit for SSL/TLS. This new OpenSSL version is a major release and incorporates many new features as well as major fixes compared to 0.9.7x. For a complete list of changes, please see http://www.openssl.org/source/exp/CHANGES . The most significant changes are: o Major work on the BIGNUM library for higher efficiency and to make operations more streamlined and less contradictory. This is the result of a major audit of the BIGNUM library. o Addition of BIGNUM functions for fields GF(2^m) and NIST curves, to support the Elliptic Crypto functions. o Major work on Elliptic Crypto; ECDH and ECDSA added, including the use through EVP, X509 and ENGINE. o New ASN.1 mini-compiler that's usable through the OpenSSL configuration file. o Added support for ASN.1 indefinite length constructed encoding. o New PKCS#12 'medium level' API to manipulate PKCS#12 files. o Complete rework of shared library construction and linking programs with shared or static libraries, through a separate Makefile.shared. o Rework of the passing of parameters from one Makefile to another. o Changed ENGINE framework to load dynamic engine modules automatically from specifically given directories. o New structure and ASN.1 functions for CertificatePair. o Changed the ZLIB compression method to be stateful. o Changed the key-generation and primality testing progress mechanism to take a structure that contains the ticker function and an argument. o New engine module: GMP (performs private key exponentiation). o New engine module: VIA PadLOck ACE extension in VIA C3 Nehemiah processors. o Added support for IPv6 addresses in certificate extensions. See RFC 1884, section 2.2. o Added support for certificate policy mappings, policy constraints and name constraints. o Added support for multi-valued AVAs in the OpenSSL configuration file. o Added support for multiple certificates with the same subject in the 'openssl ca' index file. o Make it possible to create self-signed certificates using 'openssl ca -selfsign'. o Make it possible to generate a serial number file with 'openssl ca -create_serial'. o New binary search functions with extended functionality. o New BUF functions. o New STORE structure and library to provide an interface to all sorts of data repositories. Supports storage of public and private keys, certificates, CRLs, numbers and arbitrary blobs. This library is unfortunately unfinished and unused withing OpenSSL. o New control functions for the error stack. o Changed the PKCS#7 library to support one-pass S/MIME processing. o Added the possibility to compile without old deprecated functionality with the OPENSSL_NO_DEPRECATED macro or the 'no-deprecated' argument to the config and Configure scripts. o Constification of all ASN.1 conversion functions, and other affected functions. o Improved platform support for PowerPC. o New FIPS 180-2 algorithms (SHA-224, -256, -384 and -512). o New X509_VERIFY_PARAM structure to support parametrisation of X.509 path validation. o Major overhaul of RC4 performance on Intel P4, IA-64 and AMD64. o Changed the Configure script to have some algorithms disabled by default. Those can be explicitely enabled with the new argument form 'enable-xxx'. o Change the default digest in 'openssl' commands from MD5 to SHA-1. o Added support for DTLS. o New BIGNUM blinding. o Added support for the RSA-PSS encryption scheme o Added support for the RSA X.931 padding. o Added support for BSD sockets on NetWare. o Added support for files larger than 2GB. o Added initial support for Win64. o Added alternate pkg-config files. We consider OpenSSL 0.9.8 to be the best version of OpenSSL available and we strongly recommend that users of older versions upgrade as soon as possible. OpenSSL 0.9.8 is available for download via HTTP and FTP from the following master locations (you can find the various FTP mirrors under http://www.openssl.org/source/mirror.html): o http://www.openssl.org/source/ o ftp://ftp.openssl.org/source/ The distribution file name is: o openssl-0.9.8.tar.gz MD5 checksum: 9da21071596a124acde6080552deac16 SHA1 checksum: 7350b0f0d1a6d257cb24b9d4dc5e30b80e49d6ac The checksums were calculated using the following command: openssl md5 openssl-0.9.8.tar.gz openssl sha1 openssl-0.9.8.tar.gz Yours, The OpenSSL Project Team... Mark J. Cox
[ANNOUNCE] OpenSSL 0.9.8 beta 5 released
OpenSSL version 0.9.8 Beta 5 OpenSSL - The Open Source toolkit for SSL/TLS http://www.openssl.org/ OpenSSL is currently in a release cycle. The fifth beta is now released. The beta release is available for download via HTTP and FTP from the following master locations (the various FTP mirrors you can find under http://www.openssl.org/source/mirror.html): o http://www.openssl.org/source/ o ftp://ftp.openssl.org/source/ The file names of the beta are: o openssl-0.9.8-beta5.tar.gz MD5 checksum: 4b492a622ca39f0c444c3cabc330933d SHA1 checksum: 3524b04490491e1d1674363fac601cd4b002d471 The checksums were calculated using the following command: openssl md5 openssl-0.9.8-beta5.tar.gz openssl sha1 openssl-0.9.8-beta5.tar.gz Please download and test them as soon as possible. This new OpenSSL version incorporates 104 documented changes and bugfixes to the toolkit (for a complete list see http://www.openssl.org/source/exp/CHANGES and http://www.openssl.org/source/exp/NEWS). Since the fourth beta, the following has happened: - Changed -m486 to -march=i486 in Configure. - Added a new NetWare target that uses BSD sockets. - Propagate INSTALL_PREFIX to inner Makefiles. - Make it possible to read files larger than 2GB with the FILE BIO. - Enhance cipher suite parsing. - Other bug fixes... Reports and patches should be sent to [EMAIL PROTECTED] Discussions around the development of OpenSSL should be sent to [EMAIL PROTECTED] Anything else should go to [EMAIL PROTECTED] The best way, at least on Unix, to create a report is to do the following after configuration: make report That will do a few basic checks of the compiler and bc, then build and run the tests. The result will appear on screen and in the file testlog. Please read the report before sending it to us. There may be problems that we can't solve for you, like missing programs. Yours, The OpenSSL Project Team... Mark J. Cox Nils Larsch Ulf Möller Ralf S. Engelschall Ben Laurie Andy Polyakov Dr. Stephen Henson Richard Levitte Geoff Thorpe Lutz JänickeBodo Möller - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: RSA Implementation in C language
In message [EMAIL PROTECTED] on Tue, 30 Nov 2004 10:16:11 -0500, Trei, Peter [EMAIL PROTECTED] said: ptrei Admittedly somewhat old and creaky, but try Googling ptrei RSAREF. I don't know where that stands for IP rights ptrei (presumably we still have copyright), bout for ptrei research it's a startin point. It's correct, RSA Labs have the copyright since March 16, 1994 (according to doc/license.txt that comes with RSAref 2). The license is fairly nice (although reciprocal, which some people do not like) to non-commercial users. Cheers, Richard - Please consider sponsoring my work on free software. See http://www.free.lp.se/sponsoring.html for details. -- Richard Levitte \ Tunnlandsvägen 52 \ [EMAIL PROTECTED] [EMAIL PROTECTED] \ S-168 36 BROMMA \ T: +46-708-26 53 44 \ SWEDEN \ Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ - A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Certificate serial number generation algorithms
In message [EMAIL PROTECTED] on Sun, 10 Oct 2004 18:16:21 -0700, Eric Rescorla [EMAIL PROTECTED] said: ekr Does anyone know the details of the certificate generation ekr algorithms used by various CAs? Variants I've heard of are: - A simple counter starting at 0 (well, actually, I know this one, as that's what OpenSSL does :-)) - A simple counter starting with a random value (OpenSSL has an option for this). - A time-based value (I don't recall who did that) - A hash of some sort (I believe Verisign does that, among others) - Please consider sponsoring my work on free software. See http://www.free.lp.se/sponsoring.html for details. -- Richard Levitte \ Tunnlandsvägen 52 \ [EMAIL PROTECTED] [EMAIL PROTECTED] \ S-168 36 BROMMA \ T: +46-708-26 53 44 \ SWEDEN \ Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ - A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: dual-use digital signature [EMAIL PROTECTED]
In message [EMAIL PROTECTED] on Sun, 25 Jul 2004 13:41:56 -0600, Anne Lynn Wheeler [EMAIL PROTECTED] said: lynn At 07:07 PM 7/24/2004, Peter Gutmann wrote: lynn A depressing number of CAs generate the private key themselves lynn and mail out to the client. This is another type of PoP, the lynn CA knows the client has the private key because they've lynn generated it for them. Peter, are you talking about generic CAs or in-corporation ones? I can definitely see different needs between those. lynn one could claim that there might be two possible useage lynn scenarios, involving two different thread models: encryption and lynn authentication. lynn lynn from a business standpoint the encryption of corporate data lynn (especially data at rest which might include some of the lynn corporate jewels) can represent single point of failures ... if lynn private key is required for the recovery of corporate jewels and lynn the private key isn't reliably replicated (to avoid single lynn points of failure); then there is a serious, corporate, lynn overriding availability threat. That's all and well, but I can't see why that would be interesting to a generic, third-party CA. If you're talking about a CA within the same corporation, then I can understand, since they usually (as far as I can guess) work from a different standpoint and with different priorities. What you describe feels to me like encryption is ill understood and placed in the hands of random individuals. If you want safety and recoverability, there's nothing like one or several backups, maybe protected with different means (different encryption, different storage media (including vaults), different keys, and so on). - Please consider sponsoring my work on free software. See http://www.free.lp.se/sponsoring.html for details. -- Richard Levitte \ Tunnlandsvägen 52 \ [EMAIL PROTECTED] [EMAIL PROTECTED] \ S-168 36 BROMMA \ T: +46-708-26 53 44 \ SWEDEN \ Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ - A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Fundraising for OpenSSL development
[ This is a reminder, prompted by the fact that two individuals dug into their wallets and made a small contribution each. I've also heard from a few people who are talking with their management, so far without too much else happening. Through this, I want to make it clear that small contributions from individuals are just as welcome. If you think about it, about 160 people sending USD 100 each would cover the needs stated in this fundraising document. -- Richard Levitte ] [ This is a short version of the full document. The full document, which was just updated with a slight change in USD - SEK currency exchange, is available at http://www.free.lp.se/OpenSSL-funding.html ] Levitte Programming: Fund raising for OpenSSL development Richard Levitte [EMAIL PROTECTED] Revision $Id: OpenSSL-funding.html,v 1.6 2004/07/12 11:41:08 levitte Exp $ Hello OpenSSL users and developers, I'm Richard Levitte, an OpenSSL developer. I've been active in many parts of OpenSSL, most notably in portability issues, ENGINE, UI, CONF, memory allocation and a number of other parts I forget, as well as general tinkering when and where needed. This letter is about raising funds for me to work on parts of OpenSSL that I initiated or have plans to initiate, more or less full time for at least three months, and possibly more. This letter will be kept up to date at http://www.free.lp.se/OpenSSL-funding.html. So, what's the deal? The deal is that I currently find myself a little short on job assignments except for some short ones, and therefore, my planning book is more or less empty for the rest of 2004. I would like to be able to use this opportunity to make a larger contribution to OpenSSL with some tasks that are bigger than those one can complete on one's spare time within a reasonable time frame. The tasks I'm planning on are: * to complete the STORE library, including the implementation of a few STORE accessing ENGINE modules (File, LDAP and a special one for the nCipher HSM store come in mind, and more may be added), and have it replace the current X509_LOOKUP mechanism. * to implement certificate path building that can handle simple PKIs, hierarchical PKIs, mesh PKIs, hybrid PKIs, using the current PKIX draft (currently draft-ietf-pkix-certpathbuild-03.txt) as basic document. * [OPTIONAL, if time permits] to make configuration easier to program, and to work toward a unification of all platforms so the building system looks the same everywhere. This email is an appeal to the OpenSSL user community to try to raise money for three or more months of my time to be able to dedicate time to work on the tasks shown above. Anyone can contribute, private persons as well as companies and insititutions. -- Richard Levitte \ Tunnlandsvägen 52 \ [EMAIL PROTECTED] [EMAIL PROTECTED] \ S-168 36 BROMMA \ T: +46-708-26 53 44 \ SWEDEN \ Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ - A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
