Cryptography-Digest Digest #309, Volume #13 Mon, 11 Dec 00 17:13:00 EST
Contents:
Re: important programming languages (Ed L Cashin)
Re: [Question] Generation of random keys - LONG - algorithms, randomness and
unpredictability (Bryan Olson)
Re: Newbie (Marc)
Re: Newbie (Marc)
Re: important programming languages (Bob Silverman)
Re: important programming languages ("Matthew S. Hamrick")
Re: Array shuffling (Mok-Kong Shen)
Re: binary vs. text w/ regard to digital signatures (Darren New)
Re: important programming languages ("Brian Gladman")
Re: important programming languages ("Brian Gladman")
Re: important programming languages (Jeffrey Williams)
----------------------------------------------------------------------------
From: Ed L Cashin <[EMAIL PROTECTED]>
Subject: Re: important programming languages
Date: 11 Dec 2000 15:26:15 -0500
Ichinin <[EMAIL PROTECTED]> writes:
> Tuomas Pellonpera wrote:
> > 1. C
> Good to know
>
> > 2. Java
> I wouldn't use it.
>
> > 3. Perl
> Nope.
>
> > 4. Assembler
>
> <BIG>IF</BIG> you're only going to use one piece of
> hardware or similar hardware platforms, then yes. C&C++
> lets you write programs more "near" the hardware without
> having to turn to asm.
I was interested to find that the SHA-1 stuff I am using from the
openssl library is perl-generated assembler.
That is, it's perl code that looks like this:
sub sha1_block_host
{
local($name)=@_;
&function_begin_B($name,"");
# parameter 1 is the MD5_CTX structure.
# A 0
# B 4
# C 8
# D 12
# E 16
&mov("ecx", &wparam(2));
&push("esi");
&shl("ecx",6);
&mov("esi", &wparam(1));
&push("ebp");
&add("ecx","esi"); # offset to leave on
&push("ebx");
It looks like this approach has the benefits of asm without as many of
the inconveniences, since it looks like Eric Young has made the perl
put out different asm for different platforms.
--
--Ed Cashin PGP public key:
[EMAIL PROTECTED] http://www.coe.uga.edu/~ecashin/pgp/
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: [Question] Generation of random keys - LONG - algorithms, randomness and
unpredictability
Date: Mon, 11 Dec 2000 20:19:13 GMT
David Schwartz wrote:
>
> Bryan Olson wrote:
> >
> > David Schwartz wrote:
> > >
> > > "John A. Malley" wrote:
> > >
> > > > 1) An algorithm cannot produce randomness.
> > >
> > > I'll produce a simple counterexample. First, I'll
> > > take a fairly standard definition of randomness: a stream of
> > > numbers in some base is
> > > random if all numbers are equally probable and each output is
> > > uncorrelated with respect to any previous numbers.
> >
> > Nonsense. To produce a counterexample, you have to use
> > the definition of the term that was used in the assertion.
>
> Err, what? So if someone argues that snow is black, I
> have to check to see whether if by "snow" they might have
> meant coal?
I would recommend reading a post in it's entirety before
attempting to write a refutation, but you don't "have to" of
course.
> > Malley stated that he'd use "randomness" to mean more than
> > one outcome has non-zero probability.
>
> This is the weakest definition of "randomness" I've ever seen.
That's more indicative of your lack of familiarity with the
field than of any problem with the definition. How random
need a "random variable" be, as defined in introductory texts
on probability and statistics?
In Cryptology, the most accepted notion of randomness is
entropy as defined by Shannon. Malley's definition of
"randomness" was the same as "having positive entropy". He
showed that an algorithm cannot produce positive entropy
(without being given entropy).
Entropy is a quantitative notion, and we can get a stronger
result: the entropy of the output of an algorithm is less than
or equal to the entropy of the input.
> It also has an ambiguity problem, because probability has to
> be computed with respect to some set of knowledge.
Probability is defined for a "sample space", a notion that
already captures the effects of one's knowledge. There's no
ambiguity problem with Malley's definition; it is fulfilled in
exactly those cases where the "field of knowledge" is such
that more than one outcome is possible.
> > Incidentally, a fairly common definition of random number
> > generator has each output equally probably and independent
> > of all previous outputs. I'm not sure where you got
> > "uncorrelated", which is a weaker condition than independent.
>
> If you make the definition even more restrictive, it simply
> strengthens my point.
What you wrote was that you had a counterexample to Malley's
proof, and that was simply wrong. I don't know what point you
think you have beyond that. In any case the issue is
randomness, and not the possibly more restrictive "random
number generator".
--Bryan
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Marc)
Subject: Re: Newbie
Date: 11 Dec 2000 20:33:44 GMT
>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.
------------------------------
From: [EMAIL PROTECTED] (Marc)
Subject: Re: Newbie
Date: 11 Dec 2000 20:33:55 GMT
>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
------------------------------
From: Bob Silverman <[EMAIL PROTECTED]>
Subject: Re: important programming languages
Date: Mon, 11 Dec 2000 20:44:16 GMT
In article <IaaZ5.12042$I5.127023@stones>,
"Brian Gladman" <[EMAIL PROTECTED]> wrote:
> So if you truly consider this to be no more than 'a minor nitpick'
you are
> illustrating your own lack of knowledge of the full breadth of
requirements
> for cryptographic algorithm implementation in the real world.
ROTFL.
--
Bob Silverman
"You can lead a horse's ass to knowledge, but you can't make him think"
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Reply-To: "Matthew S. Hamrick" <[EMAIL PROTECTED]>
From: "Matthew S. Hamrick" <[EMAIL PROTECTED]>
Subject: Re: important programming languages
Date: Mon, 11 Dec 2000 12:51:38 -0800
I must agree with the previous poster who said that this topic is in risk of
being beaten to death. I respond for three reasons: 1) to refute Bob
Silverberg's idea that there is only one real programming language in the
universe, 2) explain why languages like Java are important for building
crypto-enabled applications, and 3) to get in my $.02.
First off, while I respect Bob's opinion on most everything. There were
several times even at RSA when it was obvious that "the thing to do" was to
write your library in 'C', run a profiler, then use assembler to optimize
the 10% of the code that takes up 90% of the time. I'm going to guess that
Bob likes assembler because it gets one 'close to the machine' where you can
create the most optimized code. I would recommend that while this is an
important criteria for selecting your PL, it is not the only one. From my
perspective, the best criteria is, "What is the language that your user will
be using?" Of course you can always use a different language with which to
write your code, but you should make sure that the interface works with your
target audience's tools.
Java is not the ideal language for crypto. Compared to Assembler, it's slow.
There are also a few programming features that are lacking (unsigned numbers
for instance) that are not show-stoppers, but certainly make things a little
more difficult. There's also the problem that Java code is difficult to
obfuscate, a big problem if you're trying to keep your RC4(tm)
implementation a trade secret. However, from an application development
standpoint, Java is great. If I were prototyping an application myself, I
would use Python, if I were prototyping and developing an application with a
group, then Java is the answer (IMHO). There's slightly more structure in
Java, which is useful for keeping group members from jumping all over each
other. Also, no pointers make it easier for application domain experts to
learn programming. But the really cool thing about java from an app
development is the ability for code to migrate from application to
application while the applications are still running.
IMHO, start with C. It's reletively easy to code, and reletively effecient.
You can also find all sorts of existing implementations in 'C' out there
already. If you have a performance problem, use a profiler to find out where
most of your code is spending it's time, recode those routines in assembler,
then make a JNI (Java Native Interface) to make your 'C' implementation
callable from a Java application. So, what I would say: C, Assembler, and
then Java in decreasing importance. Also, consider FORTH. No one except
firmware vendors uses it anymore, but it has some great language features,
especially if you're trying to do embedded programming (like smart-cards,
iButtons, or other small devices.)
Matt Hamrick
P.S. - With respect to Python, I thought there was an active crypto
development community that uses Python. A simple search of "python crypto"
on Yahoo! produced this link that has several germain discussions:
http://www.egroups.com/list/python-crypto/
"Tuomas Pellonpera" <[EMAIL PROTECTED]> wrote in message
news:912jps$5vr$[EMAIL PROTECTED]...
> 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
>
> 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++?
> 3.) How widely used (in encryption) are Perl and especially Assembler?
> 4.) Can Python be used in encryption? If so, IS it being used, too? :)
> 5.) Did I miss an important language? (I will be switching to Linux so
> Visual Basic, for example, is out of the question.)
>
> A HUGE thank you for your help! I hope to be able to pay it back some
> day.
>
> Best wishes,
> Tuomas
>
> --
> // tuope()
> BENE VIXIT QUI BENE LATUIT
>
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
>
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Array shuffling
Date: Mon, 11 Dec 2000 22:07:34 +0100
Benjamin Goldberg wrote:
[snip]
> I submit it here for your review and comment on. Although this
> algorithm also takes a nondeterministic amount of time to complete, it
> should use N*log(N) bits on average, and the nondeterministic part is
> where you can see it, in the do/while loop, not hidden in random number
> function. This shuffler should not be biased if randbit() is not
> biased.
[snip]
I have a problem with your argument. There are 2^(N*log(N))
different bit sequences of length N*log(N), while there
are N! different permutations. N! ultimately exceeds by
far 2^(N*log(N)). Wouldn't if follow that, starting from
a fixed array content and applying all bit sequences, there
are certain permutaions that one can never get, i.e. the
algorithm is generating only a subset of all permutations,
if N is sufficiently large? BTW, doesn't your 'non-
deterministic amount of time to complete' also point to the
same direction? Thanks.
M. K. Shen
------------------------------
From: Darren New <[EMAIL PROTECTED]>
Subject: Re: binary vs. text w/ regard to digital signatures
Date: Mon, 11 Dec 2000 21:14:09 GMT
Tom St Denis wrote:
> That makes no sense. How does the decoder know how long the integer is?
ASN.1 is a TLV format, so the length isn't part of the value any more than
the type is. It actually takes more than 1 byte to store a value.
--
Darren New / Senior MTS & Free Radical / Invisible Worlds Inc.
San Diego, CA, USA (PST). Cryptokeys on demand.
Personal malapropism generator free with purchase!
Steganography: The manual is hidden in the source code.
Gold mining is only profitable because of the gold found.
------------------------------
From: "Brian Gladman" <[EMAIL PROTECTED]>
Subject: Re: important programming languages
Date: Mon, 11 Dec 2000 21:17:44 -0000
"Eric Lee Green" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> 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.
You are right that there were differences but they were not as significant
as they might seem.
My original C code was designed to test the 15 AES first round algorithms on
a level playing field - it was not designed to test the relative merits of C
and C++.
When I did the five finalists I used both C and C++ and made some more
effort to look at the relative merits of the two languages. Once I had done
this I did not find a great deal of difference - typically a few % at most.
At the moment I am using C++ rather than C because I find it has some much
better features when compared to C for crypto implementation. The ability
to encapsulate the implementation in a class is useful and the ability to
use both function inlining and templates can offer some nice optimisation
opportunities (at least it would if compiler writers would implement them
properly).
Brian Gladman
------------------------------
From: "Brian Gladman" <[EMAIL PROTECTED]>
Subject: Re: important programming languages
Date: Mon, 11 Dec 2000 21:19:43 -0000
"Bob Silverman" <[EMAIL PROTECTED]> wrote in message
news:913eav$tgi$[EMAIL PROTECTED]...
> In article <IaaZ5.12042$I5.127023@stones>,
> "Brian Gladman" <[EMAIL PROTECTED]> wrote:
> > So if you truly consider this to be no more than 'a minor nitpick'
> you are
> > illustrating your own lack of knowledge of the full breadth of
> requirements
> > for cryptographic algorithm implementation in the real world.
>
> ROTFL.
You might consider ignorance a laughing matter but I do not.
Brian Gladman
------------------------------
From: Jeffrey Williams <[EMAIL PROTECTED]>
Subject: Re: important programming languages
Date: Mon, 11 Dec 2000 16:00:00 -0600
Throwing in my $0.02, it seems to me that the "best" language depends upon the
requirements of the project, the available tools, and the available
programmers. There are probably other dimensions to the problem; those are the
three that immediately come to mind. If, within the context of the project
requirements, there are a couple of languages that would suffice, the "best
choice" would probably be the language in which your programming staff is most
competant. Your crypto algorithm needs to be implemented without errors, lest
it become somewhat less secure than you'd hoped.
IME, "best" is usually dependent upon specific circumstances, and seldom maps to
a single, general solution.
YMMV
Jeff
Brian Gladman wrote:
> "Bob Silverman" <[EMAIL PROTECTED]> wrote in message
> news:9138ks$o9q$[EMAIL PROTECTED]...
> > In article <gK8Z5.11982$I5.124606@stones>,
> > "Brian Gladman" <[EMAIL PROTECTED]> wrote:
> > > "Bob Silverman" <[EMAIL PROTECTED]> wrote in message
> > > news:912pvb$b52$[EMAIL PROTECTED]...
> > > > In article <912jps$5vr$[EMAIL PROTECTED]>,
> > > > Tuomas Pellonpera <[EMAIL PROTECTED]> wrote:
> > > [snip]
> > > > This entire discussion is "wrong-headed". Allow me to quote a
> > > > colleague: "It is possible to write Fortran in any language".
> > > >
> > > > There is really only one language that matters for encryption:
> > > >
> > > > assembler.
> > >
> > > I am inclined to agree that this discussion is not very useful but
> > your
> > > answer is wrong here for a number of reasons. Most importantly, until
> > the
> > > requirements are known it is simply not possible to decide on the best
> > > language
> >
> >
> > A minor nitpick. I did not say that assembler was "best". I was
> > very careful to avoid using that word. I did say that assembler
> > was the only choice that *mattered*. It matters when you need speed.
> > If you don't need speed then the choice of language really does not
> > matter.
>
> Wrong - if you need portable code assembler is the almost always the wrong
> choice.
>
> So in this situation what 'matters', to use your own word, is choosing a
> language for algorithm representation that provides a high level of
> portability. This is a requirement that assembler very rarely meets but high
> level languages often do.
>
> And code portability is not a minor issue for many people who have to
> implement cryptographic algorithms.
>
> So if you truly consider this to be no more than 'a minor nitpick' you are
> illustrating your own lack of knowledge of the full breadth of requirements
> for cryptographic algorithm implementation in the real world.
>
> Brian Gladman
------------------------------
** 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
******************************
