Practice Cryptography!

http://www.sniperflashcards.com/cipher.asp

Okay, this really chaps me. You have to spend $250 to get the cipher wheels and the details of the algorithm. (I got the above link from the Google ads that show up at the top of this blog -- one of the reasons I have the ads there is so I can find new things to address.)

Specifically: This guy is inviting a known-plaintext attack. You must pay in to play. My belief here is that he's planning on making enough from the number of entries to pay out the $5000 prize (that'd be $250 * 20, or 20 entries for him to make back the prize money). Plus, if you want additional known-plaintext (other clauses of the Constitution -- you don't get a chosen-plaintext against this one), that costs an additional $250, reducing the number of people who have to enter by one each time that fee is paid.

Code wheels are an interesting and odd little enigma. (Which is why the machines that the Germans used during World War II were called the "Enigma" machines.) It was largely flaws in their use that allowed them to be broken.

But why would I want to pay $250 for something that I can't cleanly verify?

eSNACC and Crypto++... eSNACC is a free (unencumbered) ASN.1->C/C++ compiler, provided by digitalnet.com. Crypto++ is a free C++ library (available at http://cryptopp.sf.net/) that can be used by eSNACC to perform some of its validation tests.

Digitalnet also supplies certificate management and verification utilities -- I'm not sure if these utilities are available for creating certificates (I've not looked at the documentation fully yet), but it seems promising.

This is all for people who are trying to avoid OpenSSL due to its numerous interface issues. As far as I can tell, these do NOT implement SSL or TLS, merely cryptography and certificate parsing/verification.

Right now, there are only a few freely-available C and C++ SSL/TLS implementations that I'm aware of... OpenSSL (and its predecessor, SSLeay), GNUTLS, and MatrixSSL. The first two provide support for client authentication as part of their free versions; the first one provides support for creation of certificates.

There is a pure Java SSL implementation available on rtfm.com; I don't use Java as a general rule so I don't know how good or efficient it is.

(This post is primarily to remind myself of things to look at and study. I'm sorry if it seems to not have much appropriateness in the larger context -- except that these implementations all are examples of current cryptographic practice. There are other implementations of cryptography -- Freenet, TOR, I2P, and a whole host of others that I'll mention later, as well as the implementations of OpenPGP, including GPG.)

But... where are they, and what assumptions do they make? And how well do they use the random numbers they get?

So I'm looking at ITU Recommendation X.693, identically published as ISO/IEC 8825-4. This is actually a fairly short one, as these things go -- it's an 18 page PDF, 4 pages of boilerplate at the beginning, 1 page for the Table of Contents, 1 page Introduction, and then finally (on page 7 of 18) get into the meat of it. However, page 9 actually starts the definition at the bottom of the page, and page 13 completes it.

Pages 14 and 15 are "Annex A": examples of each of the "Basic XML Encoding Rules" and the "Canonical XML Encoding Rules". There's also this (very sour-sounding, to my ears) note:

The length of this encoding in BASIC-XER is 653 octets ignoring all "white-space". For comparison, the same PersonnelRecord value encoded with the UNALIGNED variant of PER (see ITU-T Rec. X.690 | ISO/IEC 8825-1) is 84 octets, with the ALIGNED variant of PER it is 94 octets, with BER (see ITU-T Rec. X.691 | ISO/IEC 8825-2) using the definite length form it is a mininum of 136 octets, and with BER using the indefinite length form it is a minimum of 161 octets.

I suppose worrying about record sizes does make some sense if you're worrying about information being transmitted over a 56kbps link... but it doesn't make sense nowadays, as far as I'm able to tell, with the Web.

I wonder if I can coax Sleepycat DBXML to let me put something in in BASIC-XER and pull it out as CANONICAL-XER.

But anyway, after all of this, there's 2 blank pages (without even the self-defeating "this page intentionally left blank" text), and then 1 last page of boilerplate.

How someone's supposed to actually use this in any kind of signature system is outside of my realm of ability to think at the moment -- then again, I'm also rather ill, so I'm not thinking as clearly as I otherwise would be.

Y'know, I gotta wonder... why don't CAs just embed their CPS's directly into their certificates? (Granted, this is another X.509-type question, and I've pointed out many flaws with X.509 already.)

To be fair to Mr. Ritter (of http://www.ciphersbyritter.com/), I have been doing some thinking on his proposition that different algorithms (even untested, unanalyzed ones) should be used, and it has at least a bit of merit:

if the main algorithms are broken, then what do we do with all the data that's now unlocked?

Personally, my general stance is to encrypt everything at least twice (with different ciphers), but that adds to the processing overhead. And how about asymmetric authentication and/or encryption algorithms? Encryption with RSA is several orders of magnitude slower than encryption with a block or a stream cipher... but everyone has RSA keys, not DH keys.

Much less any other asymmetric algorithm's keys.

This bears more thought, and I may yet decide that he's correct and that I've been thinking along the wrong lines. However, I still think that I'd prefer to see at least some analysis.