Cryptography-Digest Digest #310, Volume #13 Mon, 11 Dec 00 20:13:01 EST
Contents:
Re: document signing, XML canonicalization and why EDDF is a better (lcs
Mixmaster Remailer)
ElGamal questions ([EMAIL PROTECTED])
Re: important programming languages (Andre van Straaten)
Notice of export of freely-available cryptographic source code (Eric Lee Green)
Re: How to embed a key in executable code? ([EMAIL PROTECTED])
Re: Newbie (Andre van Straaten)
Re: Newbie (Andre van Straaten)
Unguessable sequence of unique integers? (Johan Hanson)
Re: important programming languages (Paul Schlyter)
Re: important programming languages (Tim Tyler)
Re: Array shuffling (Bryan Olson)
Re: document signing, XML canonicalization and why EDDF is a better (denis bider)
Re: [globera announcement 1] "Efficient Descriptive Data Format" preliminary
specification and SDK released ([EMAIL PROTECTED])
Re: important programming languages (Tim Tyler)
----------------------------------------------------------------------------
Date: 11 Dec 2000 21:40:36 -0000
From: lcs Mixmaster Remailer <[EMAIL PROTECTED]>
Subject: Re: document signing, XML canonicalization and why EDDF is a better
Denis Bider writes:
> (1) If you have a system that generates regular (non-canonical) XML
> documents; and if you need documents in their canonical form, which
> you probably will; you will have to convert documents from
> non-canonical form to canonical form all the time. This is a lot of
> unnecessary extra effort that involves a complex set of rules, is
> error-prone and opens potential vulnerabilities.
As you are undoubtedly aware, the XML-Signature working group
(http://www.w3.org/Signature/) has defined canonicalization transforms
specifically for this purpose. The XML is parsed and the tree is then
canonicalized to fill in default values and create a unique ordering.
This is what is hashed for the signature.
While this may seem expensive to do on every signature verification,
most of the work is involved in parsing the XML, which usually must be
done anyway in order to locate the signature which is enmeshed in the
XML data. Once you have it parsed there is usually a relatively limited
amount of alteration which has to be done for the canonicalization.
Essentially, this problem has been solved already in the XML world.
Authors of XML need very little awareness of canonicalization issues.
It is all taken care of by the signature software. Of far more concern
are issues relating to seeing what is signed and signing what is seen,
especially relevant to XML since it is often transformed into HTML
for viewing.
------------------------------
From: [EMAIL PROTECTED]
Subject: ElGamal questions
Date: Mon, 11 Dec 2000 23:03:36 GMT
Hi, I'm new on security so correct me if I'm wrong.
In public key algorithms like ElGamal the message to
be encrypted is actually encrypted using a simetric
algorithm. And the key of the Simetric is encrypted
using the public key.
I need to encrypt messages no longer than 128 bits
and the performance is very important.
So I was thinking on taking the simetric algorithm and
use "pure" Elgamal to encrypt my data, I mean using the
algorithm used to encrypt the simetric key to encrypt my data.
Someone knows if this is "secure" and where to get a simple
implementation (C/C++) of this algorithm that I can modified
to achieve this?.
Thanks in advance.
Jorge
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Andre van Straaten <[EMAIL PROTECTED]>
Subject: Re: important programming languages
Date: Mon, 11 Dec 2000 23:25:21 GMT
Tuomas Pellonpera <[EMAIL PROTECTED]> wrote:
> Hi!
> I found out that at the end of last February there was a rather lengthy
> (50 articles or so) discussion about 'the best programming language for
> encryption'. However, as some questions remained unanswered to me, and
> as I have just joined this group, I dare pose them now.
> To begin with, I got interested in programming thanks to Eric S.
> Raymond's aricle 'How to become a hacker' (= wizard programmer). He
> recommends these languages: C/C++, Python, Perl, Java and LISP. As my
> main area of interest is cryptography, I have tried to select languages
> that would offer a steady basis for writing and developing encryption
> programs (last February's discussion on the subject helped me). They are
> (not in order of importance):
> 1. C
> 2. Java
> 3. Perl
> 4. Assembler
I assume you want to write programs on your desktop mainly for your own.
Often the choice of the languages is determined by the project.
Points are: legacy code, specific libraries, co-workers, processors
(8-bit embedded device, or 64-bit desktop, e.g.), client platforms.
> 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++?
The adavantage of C++ comes with larger projects. For math is C often
faster. OO brings a little overhead which has an impact only for fast
real-time applications.
> 3.) How widely used (in encryption) are Perl and especially Assembler?
Perl has many crypto packages and is fine for algorithms. Assembler is
mostly used for emdedded devices with few space in ROM and RAM.
> 4.) Can Python be used in encryption? If so, IS it being used, too? :)
Besides some simply crypto tools you better forget, is there the NumPy
package.
> 5.) Did I miss an important language? (I will be switching to Linux so
> Visual Basic, for example, is out of the question.)
My FreeBSD box has no VisualBasic, but two BASIC interpreters installed.
You never know ;-)
I would look for the best math libraries, if your intention is to do
something more complicated than OTP and RC5.
Fortran and C have generally the best performance, in case you really
are interested in speed.
32-bit Assembler is quite difficult - much more than 8-bit Assembler,
e.g., as every Assembler depends strongly on the processors's
architecture, you have to understand first, before you can write
programs better than an average compiler would do.
In all other cases, it depends on so much different things, that
it can't be explained shortly.
My advice, learn as many languages as possible, if you don't depend
on money or timelines.
Every languages has pro and cons.
Knowing more languages lets you read more different source code and
let's you mess with more existing legacy code.
A last word to Lisp or Scheme (a stripped down dialect of Lisp).
Some mathematicians write their proofs in these languages.
They are full-fledged general-purpose languages, too.
-- avs
Andre van Straaten
http://www.vanstraatensoft.com
------------------------------
From: Eric Lee Green <[EMAIL PROTECTED]>
Subject: Notice of export of freely-available cryptographic source code
Date: Mon, 11 Dec 2000 16:31:25 -0700
Persuant to 15 CFR Part 734, as revised on January 14, 2000, notice is
hereby given that files including freely-available (open source)
source code for cryptographic functions is being published on the
World Wide Web at URL:
http://aescrypt.sourceforge.net/
Specifically:
AESCrypt: Rijndael encryption for shell scripts.
--
Eric Lee Green [EMAIL PROTECTED]
Software Engineer "The BRU Guys"
Enhanced Software Technologies, Inc. http://www.estinc.com/
(602) 470-1115 voice (602) 470-1116 fax
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: How to embed a key in executable code?
Date: Mon, 11 Dec 2000 23:34:34 GMT
In article <N4xY5.66454$[EMAIL PROTECTED]>,
"Matt Timmermans" <[EMAIL PROTECTED]> wrote:
> My point is that we have nothing but faith and experience to suggest
that
> reverse engineering is feasible. Faith and experience is enough to
say that
> reverse engineering is _usually_ feasible, but if you want to say that
> reverse engineering is _always_ feasible, you need proof.
Actually we have quite a bit more than that. What we have is a known
cryptographic situation. This situation is quite simply, that Alice and
Bob are the same person, and Alice/Bob wants to reveal information
about the communication. I don't care what protocol you use, how
sophisticated it is, or even how much trouble is involved. There is no
way to stop Alice/Bob from revealing the information. It really is that
simple. It is possible to make it difficult for Alice/Bob to reveal the
information, by obscuring what was done even from them, but it simply
cannot be done completely.
In case you'd like a more precise model I'll elaborate. Alice is the
user (actually the person that will pirate your software). Bob is
Alice's computer. Alice tells Bob to run program P, but observe every
action that it takes in complete detail (which is possible because to
Bob the program is not a black box). Alice asks Bob to reveal all the
information to Alice, because Alice is the one with a brain to examine
what is happening. Alice does not have to figure out every detail of
what is being done, only enough to fake a correct response from the
verification, this could be done through removing code from the
program, adding code to the program, changing code, altering disk data,
etc. Because Alice is collaborating with Bob to break the security that
is between them there is NOTHING that anyone else can do except prevent
Alice and Bob from having that program, which is an entirely different
question.
Joe
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Andre van Straaten <[EMAIL PROTECTED]>
Subject: Re: Newbie
Date: 11 Dec 2000 17:38:54 -0600
Marc <[EMAIL PROTECTED]> wrote:
>>Given that no one but me has the algorithm, I still feel it is secure
>>(as keep the algorithm to my self.)
> I just lock my secrets away in a safe. Very secure and works without
> any math. I just better don't talk about it nor about where the safe
> is nor let anyone surf my shoulder when I unlock it. Probably I should
> ask you all to forget about it now and to not save this message to
> disk. Thank you for cooperation.
> X-no-archive: yes
> errrrrr. jodido
I have another method which is as secure as the OTP:
I just don't have secrets.
LOL
-- avs
Andre van Straaten
http://www.vanstraatensoft.com
====== Posted via Newsfeeds.Com, Uncensored Usenet News ======
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
======= Over 80,000 Newsgroups = 16 Different Servers! ======
------------------------------
From: Andre van Straaten <[EMAIL PROTECTED]>
Subject: Re: Newbie
Date: 11 Dec 2000 17:46:29 -0600
Marc <[EMAIL PROTECTED]> wrote:
>>I will give the program that uses the algorithm to my friends. It is up
>>to them to keep the program secure.
> Imagine you protect offensive material with your algorithm and the
> law enforcement wants to read it. They ask for the code and you,
> having just eaten the disk, say you can't comply, sorry. Data's lost.
> Now your future is in the hands of your friends. Will they supply
> their copy of the program? Will they be raided for smoking pot and
> the program be found by coincidence?
> Well, if the algorithm is the secret already, you should design a new
> one for every file you want to protect - so that when one file is
> compromised, the others are not as well.
"design a new one for every file you want to protect" - good idea but
how should this be done?
I'm not King Math.
-- avs
Andre van Straaten
http://www.vanstraatensoft.com
====== Posted via Newsfeeds.Com, Uncensored Usenet News ======
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
======= Over 80,000 Newsgroups = 16 Different Servers! ======
------------------------------
From: Johan Hanson <[EMAIL PROTECTED]>
Reply-To: moc.qit@nahoj
Subject: Unguessable sequence of unique integers?
Date: Tue, 12 Dec 2000 00:16:57 GMT
Hello.
I am looking for an algorithm for a generator of a sequence
of unique and unguessable 32-bit integers.
The number of integers created by the sequence must be
very large, i.e. in the 32-bit range and no two values
in the sequence must overlap until a fairly large number
(a minimum of 2^24 or so) of values have been found.
I suppose I could do this by using a simple counter
and encrypting the result with a symmetric algorithm.
Is there a good freely available implementation of a simple
algorithm?
.. but more interestingly, is there any better way of creating
the sequence?
Thanks in advance for any replies.
/ Johan
(my reply-email is backwards)
------------------------------
From: [EMAIL PROTECTED] (Paul Schlyter)
Subject: Re: important programming languages
Date: 12 Dec 2000 00:32:58 +0100
In article <[EMAIL PROTECTED]>,
JCA <[EMAIL PROTECTED]> wrote:
> Bob Silverman wrote:
>
>> There is really only one language that matters for encryption:
>>
>> assembler.
>
> You can say that again. It is true that compilers are getting
> better and better, but for a number of cryptographic operations
> good, hand-coded assembly language at the right place buys
> you one order of magnitude in performance. The gains are most
> noticeable for newer architectures, for which compilers are not
> yet so hot.
Perhaps one should then say:
There is really only one language that matters for encryption:
hardware.
because hardware implementations will buy you another order of
magnitude in performance.
--
================================================================
Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
e-mail: pausch at saaf dot se or paul.schlyter at ausys dot se
WWW: http://hotel04.ausys.se/pausch http://welcome.to/pausch
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: important programming languages
Reply-To: [EMAIL PROTECTED]
Date: Mon, 11 Dec 2000 23:53:20 GMT
Niklas Frykholm <[EMAIL PROTECTED]> wrote:
: Python falls in the same category as Perl. Python's advantage is that it
: is much easier to learn. The disadvantage is that it is harder to
: find good third-party modules. [...]
I believe http://www.jpython.org/ can help with this somewhat.
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Free gift.
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: Array shuffling
Date: Tue, 12 Dec 2000 00:17:37 GMT
Benjamin Goldberg asked:
[...]
> Where could I find a description of how a maximally efficient modran
> function works? Most of the ones I've seen simply aren't.
Here's one:
/* Return an int uniformly distributed in [0 .. bound-1]. */
/* Assumes rand_bit() returns independent uniform random bits. */
int rand_in_range(int bound)
{
int rand = 0;
int current_bound = 1;
for (;;)
{
while (current_bound < bound)
{
/* rand is uniform in [0 .. current_bound-1]. */
rand = rand * 2 + rand_bit();
current_bound = current_bound * 2;
}
if (rand < bound)
/* rand is uniform in [0 .. bound-1]. */
return rand;
/* rand is uniform in [bound .. current_bound-1]. */
current_bound -= bound;
rand -= bound;
/* rand is uniform in [0 .. current_bound-1]. */
}
}
The comments form a sketch of a proof of correctness.
Termination is un-provable, since it's a non-terminator, but
one can show it terminates with probability 1. I'd like to
see a simple proof of optimality (or counterexample, just in
case I made a mistake).
--Bryan
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (denis bider)
Subject: Re: document signing, XML canonicalization and why EDDF is a better
Date: Tue, 12 Dec 2000 00:45:10 GMT
On 11 Dec 2000 21:40:36 -0000, lcs Mixmaster Remailer
<[EMAIL PROTECTED]> wrote:
>> (1) If you have a system that generates regular (non-canonical) XML
>> documents; and if you need documents in their canonical form, which
>> you probably will; you will have to convert documents from
>> non-canonical form to canonical form all the time. This is a lot of
>> unnecessary extra effort that involves a complex set of rules, is
>> error-prone and opens potential vulnerabilities.
>
>As you are undoubtedly aware, the XML-Signature working group
>(http://www.w3.org/Signature/) has defined canonicalization transforms
>specifically for this purpose. The XML is parsed and the tree is then
>canonicalized to fill in default values and create a unique ordering.
>This is what is hashed for the signature.
A good point. I do agree that most of the advantage that an
alternative scheme like EDDF might offer would be hidden within the
realm of the parser/signature code. It is primarily this code that
would be made less complex by using a format like EDDF. Externally,
the only visible difference would be a somewhat smaller document size.
(XML documents generally shrink by about 25% when converted to EDDF)
And the fact that you need another parser.
It seems that at this moment, it is definitely not the right time for
something like EDDF. The hype of XML is too big, and everyone is
concentrating on trying to understand what XML is, anyway. At this
point, EDDF is an unnecessary distraction to most people. (As
demonstrated by the more "intellectual" contributors to this newsgroup
- the cryptographers who have never heard of ASN.1 :-)
I'd like to thank you all for submitting your comments and for taking
your time. I will continue to work on EDDF at a peaceful rate - feel
free to check out www.eddf.org from time to time.
Kind regards,
denis
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: [globera announcement 1] "Efficient Descriptive Data Format" preliminary
specification and SDK released
Date: Tue, 12 Dec 2000 00:45:01 GMT
Lets start over at the beginning here because the other subthreads
don't seem to be getting anywhere. Here's the way I see it:
Advantage:
data is already binary so binary transfer is logical
Disadvantage:
that means that when transferring you are forced to base-64 the whole
thing, which is obviously more time consuming that base-64ing small
peices as in XML
Disadvantages:
ASN.1, that alone is enough of a reason to avoid your system
Ignorance on designer's part, see above comment
arrogance on designer's part, see above
Massive quantities of known plaintext if this thing is ever encrypted,
see above
bloat, bloat, bloat, bloat, bloat, I have never seen an ASN.1 based
format that didn't involve astonishing amounts of bloat
new format, supported only by one individual, see comment 2 and 3 for
details about the individual
I'm sorry, but based on my review of this concept, I cannot condone the
forcing of this format to remain among the living.
Joe
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: important programming languages
Reply-To: [EMAIL PROTECTED]
Date: Mon, 11 Dec 2000 23:58:22 GMT
John Savard <[EMAIL PROTECTED]> wrote:
[programming languages for encryption?]
: [The] languages mentioned are currently popular ones
: which do lend themselves to efficient implementation of contemporary
: encryption algorithms - in their areas of use, Java and Perl being
: more or less interpreted.
Neither Java nor Perl are "more or less interpreted", IMO.
In particular, Java has had JITs for years, now. These days, you get a
runtime-profiniling, optimising JIT with practically any decent JVM.
Java is very frequently compiled to native code. About the only place
Java is interpreted these days is in embedded systems - where there'e no
room for a JIT.
--
__________ http://alife.co.uk/ http://mandala.co.uk/
|im |yler [EMAIL PROTECTED] http://hex.org.uk/ http://atoms.org.uk/
------------------------------
** 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
******************************
