Cryptography-Digest Digest #307, Volume #13 Mon, 11 Dec 00 12:13:01 EST
Contents:
Re: important programming languages (Eric Lee Green)
Re: binary vs. text w/ regard to digital signatures ([EMAIL PROTECTED])
Re: important programming languages ([EMAIL PROTECTED])
DNA crypto (lit.) (Mok-Kong Shen)
Re: binary vs. text w/ regard to digital signatures (denis bider)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Eric Lee Green)
Subject: Re: important programming languages
Reply-To: [EMAIL PROTECTED]
Date: Mon, 11 Dec 2000 16:07:14 GMT
On Mon, 11 Dec 2000 13:11:26 GMT, Tuomas Pellonpera <[EMAIL PROTECTED]> wrote:
>Hi!
> 1. C
> 4. Assembler
Note that "C" is basically a high level assembler for the DEC PDP/11
(grin).
You will always get the best performance for multi-precision math (as
used in public key encryption) by using assembler, but usually you can
"cheat" and use somebody else's multi-precision math library that has
already hadd the assembler bits written (such as GNU MP, which
somebody tells me is "Bloody Fast!" compared to his multi-precision
math routines written in "C"). That way you can write in "C" without
worrying about performance.
Most low-level ciphers should be written in "C" for performance. Dr.
Gladman has benchmarked "C" vs. C++ for cipher work, and found that "C"
has some decided performance advantages.
> 2. Java
Important primarily for cross-platform work. Speed can be problematic if
you are not running your routines on a fast JIT runtime.
> 3. Perl
As always, Perl is a "glue" language, capable of calling other
encryption routines but too slow at bit-boffing to write encryption
routines in. There is a Perl (and a Python) interface to the OpenSSL
libraries which makes Perl (or Python) useful for writing encryption
systems -- i.e., the high level parts that actually use the low level
encryption routines. A few limited things can be done using the GNU MP
interfaces for Perl and Python... e.g., I do Diffie-Hellman using
Python and its 'mpz' interface. The performance is acceptable because
I don't do a jillion Diffie-Hellman key exchanges per second, and in
fact if I do more than a dozen after the system has been set up
there's probably something wrong.
>My questions are:
>1.) Would you agree that these language are, not the only right and best
>ones, but ones that offer a solid background for encryption?
>2.) Would it be useful to know both C and C++?
C++ is useful to know, certainly.
>3.) How widely used (in encryption) are Perl and especially Assembler?
Assembler is used heavily in multi-precision math routines, but you
can usually avoid having to actually know assembler. Especially if
you're doing Linux, where assembler is very little used (due to the
fact that Linux runs on so many different processors).
>4.) Can Python be used in encryption? If so, IS it being used, too? :)
Yes, Python has an interface to the GNU MP library's mpz module for
doing multi-precision math, and the OpenSSL library for doing a
variety of encryption. You will not, however, write an actual
encryption algorithm using Python, generally -- you'll just use it as
the glue for your entire cryptosystem (which comprises not only the
modules, but the protocols). BRU Professional, EST's new small
enterprise/workgroup backup product (http://www.estinc.com), uses
Python and cryptographic components heavily -- its tape server is
written mostly in Python, and when I did the key exchange and
authentication scheme for the network protocols, I glued the low level
"C" routines that implement the actual encyrption algorithms together
with Python. I wrote the actual Diffie-Hellman key exchange in Python, using
the low-level 'mpz' math modules (see description up above).
>5.) Did I miss an important language? (I will be switching to Linux so
>Visual Basic, for example, is out of the question.)
"C" is the primary language for Linux. /bin/sh, Python, and Perl are
the primary glue languages. C++ is occasionally used on Linux,
especially for the "K" Desktop Environment. Java is rarely used on
Linux, primarily due to historical/political reasons (there were
historically few good Java runtimes for Linux, and the source was not
publically available for free use, an anathema for the Open Source
crowd).Assembly language is almost never used on Linux, due to the
cross- platform nature of Linux (a routine in 8086 assembler doesn't
do you much good on a SPARC!).
The most useful programs are those that can be used as components in
shell scripts (/bin/sh), which appears to be the main "language" you
missed. For example, I have a secure remote authentication protocol
whereby which a user name and password is passed over the network
encrypted via AES and a salt, and the program that does the decrypting
and checking of whether this is a valid password is actually a shell
script that calls a program (aesdecrypt) to decrypt the password, and
pipes that output to another program (checkpam or checkcrypt) to
verify whether that is a valid password in that machine's password
file (or wherever else that machine gets its user info). Remember the
Unix philosophy -- 'many small programs that do one thing glued
together into larger systems.' This applies to cryptographic systems
too. In many cases, it's not necessary to have a large monolithic
system, except for political reasons (e.g., "well, that's how it's
done on Windows NT and this program must be portable to Windows
NT"). If my team can write an enterprise backup product as hundreds of
Python scripts glued together by some network daemons and in turn
gluing together 'aescrypt', 'checkpam', 'checkcrypt', MySQL, 'mtx',
'bru', etc., I suspect there are very few Unix programs indeed that
need to be huge undebuggable monolithic programs. (Sorry, my pet peeve
here -- Unix programs that are written as if they were Windows NT
programs, as one huge undebuggable multi-threaded mess).
--
Eric Lee Green There is No Conspiracy
[EMAIL PROTECTED] http://www.badtux.org
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: binary vs. text w/ regard to digital signatures
Date: Mon, 11 Dec 2000 15:34:09 GMT
denis bider <[EMAIL PROTECTED]> wrote:
> EDDF solves this by being a binary format. There is no whitespace.
Wuzzerful. My car solves the problem of airport delays by not being a
plane.
> EDDF solves this by being a binary format. It uses content length
> instead of delimiters; hence, no need for escape sequences.
In other words, it trades the pain of escape sequences for the pain of
endianess, and every other binary issue.
> EDDF uses canonical UTF-8 for all character data. Such a UTF-8 string
> is equal to another UTF-8 string when the encodings are equal. No
> dilemma.
Except, of course, when confronted with a system which doesn't support
unicode. And the not-so-simple character overflow problems that always
come piggybacking in on unicode.
Essentially what you've settled on is a system that's slightly better
than ascii for the majority of characters, and slighty more fun than
repeated blows to the head with a hammer for a minority of characters.
> (4) Binary data.
> How are you going to include binary data in an XML document?
> There are two widespread ways to do it: HEX and Base64 encoding.
Many people might simple include it via an external resource. Unless
you seriously believe that publishers base64 illustrations before
printing.
> EDDF specifies a canonical (binary) form for the encoding of numeric
> values.
With what sort of precision? Can I store a 512 bit integer? Are there
seperate types for ints and reals? Do I get the incredable advantage
of always taking at least 32 bits to store '1'? Or is it 64 or more,
since you're thinking long term? If it's a rental agreement I want
someone to sign, will it automatically put problematic values like
$1.25 into an improved canonical form like 1.25000000000000000
dollars?
> (6) ...
> I think you can see that comparing two XML documents is not a trivial
> task. A complex bunch of rules is required to handle comparisons
> between XML documents. Yes, these rules have been defined and in the
> near future, they will be implemented in conforming XML parsers. But
> technically, the whole thing is rather awkward. As far as security is
> concerned, choosing a text-based format was the wrong decision.
What I can see is that comparing any two documents is not a trivial
task. If it were, Perry Mason would have run for ten fewer episodes.
In fact, in the absolute worse case scenario, instead of dragging
plain text into court, we can now drag kilobytes of UTF8. That has the
promise of making the Florida election look simple.
> EDDF has been designed to provide all the functionality of XML, plus
> the ability to compare two documents on a binary basis. If their
> encodings are equal, the documents are equal.
I'll grant you that EDDF has been designed to "compare two documents
on a binary basis" but not that it provides all the functionality of
XML. Wether or not the comparison is a desireable feature is an open
quesion.
Basically, what you might have is something interesting for specific
applications, rather than a brand-new publishing standard set to take
the world by storm.
--
Matt Gauthier <[EMAIL PROTECTED]>
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: important programming languages
Date: Mon, 11 Dec 2000 16:23:09 GMT
Tuomas Pellonpera <[EMAIL PROTECTED]> wrote:
> My questions are:
> 1.) Would you agree that these language are, not the only right and best
> ones, but ones that offer a solid background for encryption?
I would point you to the other replies which indicate that there's
really no such thing as a "best" programming language. That fallacy
being addressed, I'll proceed to limit the conversation to
cryptography and answering your questions.
> 2.) Would it be useful to know both C and C++?
Yes. It's rarely _not_ usefull to be exposed to a new language. On the
other hand, C++ is the dog's dinner when it comes to learning about
object-oriented programming. It's highly useful for some tasks though,
none of which you're likely to be undertaking any time soon. I
personally would put it on the back burner, until you're comfortable
with java, and python.
> 3.) How widely used (in encryption) are Perl and especially Assembler?
Perl's used sometimes, not often, but see below. Assembler is
predominatly used where things can't be expressed efficiently in C,
which is rare.
> 4.) Can Python be used in encryption? If so, IS it being used, too? :)
It could be, but I don't recall seeing any prominant examples offhand.
> 5.) Did I miss an important language? (I will be switching to Linux so
> Visual Basic, for example, is out of the question.)
LISP. Not for any connection at all to cryptography, but because
either LISP or scheme will illustrate a different way of looking at
problems than any of the others, which is never a bad thing.
On a language-specific note:
I would say a working knowledge of C is essential, not just for
cryptography. It's almost impossible to program anything, in any
language, on Linux without understanding concepts that can only be
expressed in C. You'll also find more code floating around in C than
any other language. I'd make this stop #1.
Java, all of the hype and bad press aside, is a reasonably nice OO
language. The good news is it's well-designed and easy to use, the bad
news is it's hard to find a good book and has a learning curve wholey
out of proportion with the size of the core language due to the huge
libraries. It offers, in my opinion, two wonderful features not found
anywhere else for cryptography, standard widths for data types and a
well-defined interface for cryptographic extensions. I'd look at it
second.
Armed with a solid knowledge of C, OO tecniques, and common data
structures, I'd move on to perl. Perl is a horrible, ugly, disaster of
a language written in a crazed fit by a complete mad man. It's also
the best thing since sliced bread for data reduction and text
processing. The hodgepoge of features make it a nice tool for
cryptanalysis. Any time you're wondering things like "How can I print
out a table of character frequencies sorted from most to least
frequent in 300 files?" you're probably looking for perl. It's not,
however, the sort of language that encourages structured or
well-designed programs, which is one reason I recommend it last.
Which brings us to perl's cousin, python. Alot of people see them as
contary, rather than complementary, but I think that's a
mistake. Python is good at everything perl is bad at, and vice
versa. Python also uses dynamic types, but has a much cleaner
syntax. Unlike perl, it gives you the impression of being designed,
rather than acumulated and supports a coherent version of OO
techniques. It is, in my opinion, much easier to extend than perl, and
more suitable for large projects.
So when would I learn Python? I don't know. Alot of people recommend
it as a first language, for which it's probably a good choice. I would
use it in a class without reservations. Books, however, are somewhat
more limited than for other languages, so learning it alone might be a
beast. It's simpler than java, but doesn't introduce as many new
concepts. In short, it's worth a look, whenever you get to it,
probably right after perl.
Which brings us to the last few again, assembler, C++, and lisp. Lisp
is worth being familiar with, and is taught first in alot of
places. To me, however, it's contrary enough to the way people think
that it's a bear to get a handle on without a mentor. I reccomend he
dabbling approach, doing little bits of work in it here and there,
seeing if you like it. Personally, the only lisp code I have surving
around here is the initialisation file for emacs.
Assembler is a nice way of learning how the computer actually
works. Unfortunatly, I'm of a somewhat mixed mind on the current Intel
instruction sets. I think they're a bit large to work with unless
you're going to be doing tons of work in assembler. The first language
I ever used was actually assembler in a software simulation of a small
cpu with limited functionality. While some exposure's good, I'd dabble
in this too. I wouldn't write _anything_ in it except for fun until
you've mastered profiling and performance tuning in general, and are
comfortable with algorithms and data structures.
Speaking of data structures, that brings us to C++, king of the data
structure hill. Anything I said about crazed design regarding perl may
apply ten fold in this case. The C++ libarary provides, among other
things, an impressive array of generic data structures and
algorithms. Java does too, but doesn't provide the amount of rope C++
does for hanging yourself. In short, C++ does everything, at the
expense of letting you do anything. It's the nail gun, circular saw,
and wrecking ball of the programming world all rolled into one. It's a
powerful tool, but requires enough discipline and style on the part of
the author that you definately want at least one, preferably two
languages firmly under your belt before looking at it.
--
Matt Gauthier <[EMAIL PROTECTED]>
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: DNA crypto (lit.)
Date: Mon, 11 Dec 2000 17:51:33 +0100
I saw a paper on DNA steganography at
http://ls11-www.cs.uni-dortmund.de/molcomp/Publications/PubKey.pdf
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (denis bider)
Subject: Re: binary vs. text w/ regard to digital signatures
Date: Mon, 11 Dec 2000 16:58:38 GMT
On Mon, 11 Dec 2000 15:34:09 GMT, [EMAIL PROTECTED] wrote:
OK Matt, I judge from your reply that this debate really gets on your
nerves, because it shows. Nevertheless, I will try to respond sensibly
where at all possible.
>> EDDF uses canonical UTF-8 for all character data. Such a UTF-8 string
>> is equal to another UTF-8 string when the encodings are equal. No
>> dilemma.
>Except, of course, when confronted with a system which doesn't support
>unicode. And the not-so-simple character overflow problems that always
>come piggybacking in on unicode.
Matt, do you know anything at all about UTF-8? Are you aware of the
fact that your message, when you posted it, was a valid UTF-8 string?
Do you know that UTF-8 is equivalent to ASCII for all characters with
ASCII code lower than 128, and that compatibility with ASCII was one
of the intentions of its design?
When confronted with a system which doesn't support Unicode, an EDDF
document will cause as much problems as any XML document.
What is more - a non-Unicode system will be able to process any EDDF
document, because the binary format remains the same, whether national
characters are being used or not. However, a non-Unicode system will
not be able to understand an XML document if it is encoded with, say,
UCS-2.
>Essentially what you've settled on is a system that's slightly better
>than ascii for the majority of characters, and slighty more fun than
>repeated blows to the head with a hammer for a minority of characters.
Statements like this show your ignorance.
>> How are you going to include binary data in an XML document?
>Many people might simple include it via an external resource. Unless
>you seriously believe that publishers base64 illustrations before
>printing.
A digital signature happens to be binary data which is not appropriate
for inclusion via an external resource.
A document that contains thousands of records from an SQL server,
where one of the columns is, eg, an image, is also not a candidate for
inclusion via an external resource.
Basically, if you are processing something, it is easiest if you can
get everything you need from a single source; binary data included.
>> EDDF specifies a canonical (binary) form for the encoding of numeric
>> values.
>With what sort of precision? Can I store a 512 bit integer?
Of course. As easily as a 2-bit integer, and as easily as a 12345-bit
integer.
> Are there seperate types for ints and reals?
Of course.
> Do I get the incredable advantage of always taking at least 32 bits to store '1'?
No, it takes 1 byte to store 1. It also takes 1 byte to store 255, 2
bytes to store 256, and so on.
> If it's a rental agreement I want someone to sign, will it automatically put
> problematic values like $1.25 into an improved canonical form like
> 1.25000000000000000 dollars?
No, $1.25 would be encoded as a decimal type, where mantissa = 125 and
exponent = -2.
>I'll grant you that EDDF has been designed to "compare two documents
>on a binary basis" but not that it provides all the functionality of
>XML. Wether or not the comparison is a desireable feature is an open
>quesion.
Based on your arguments you didn't even care to take a look at its
specification. You don't even know what DER encoding is, and you have
no idea about UTF-8.
How can you, then, make such judgements about a technology you don't
have anything but prejudice about?
Of course EDDF provides all the functionality of XML, that is what it
has been designed to do. If you want to prove this statement wrong,
the minimum that you should do is take 15 minutes and skim the
specification.
Seeing that you know nothing about DER either, there's also a layman's
guide to ASN.1 available from http://www.rsasecurity.com/rsalabs/pkcs.
Maybe you should look at that, too.
>Basically, what you might have is something interesting for specific
>applications, rather than a brand-new publishing standard set to take
>the world by storm.
So you figured it out, haven't you?
- denis
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
