Cryptography-Digest Digest #329, Volume #13 Thu, 14 Dec 00 16:13:00 EST
Contents:
Re: Software PRNG.. (Terry Ritter)
Re: important programming languages (Michael Erskine)
Re: ethical considerations ... (Mike Rosing)
Re: KEYEVAL again was - Crypto Program for HP48GX Calculator ("Veli-Pekka
Nousiainen")
Re: Protocol for computer go (David Wagner)
Re: Protocol for computer go (David Wagner)
Re: Unguessable sequence of unique integers? (Bryan Olson)
Re: security by obscurity ... (David Wagner)
Re: ethical considerations ... ("Peter Thorsteinson")
Re: security by obscurity ... ("Peter Thorsteinson")
Re: ethical considerations ... (John Savard)
Re: ethical considerations ... (wtshaw)
Re: security by obscurity ... (David Wagner)
Re: ethical considerations ... (Paul Rubin)
Re: Visual Basic Source Code ([EMAIL PROTECTED])
Re: Crypto Program for HP48GX Calculator (Richard Hutchinson)
Re: ethical considerations ... ("Peter Thorsteinson")
Re: Protocol for computer go (David Eppstein)
discrete math textbook ([EMAIL PROTECTED])
Re: Visual Basic Source Code (Simon Johnson)
Re: ethical considerations ... (Simon Johnson)
Re: important programming languages ("Douglas A. Gwyn")
Re: On using larger substitutions (Mok-Kong Shen)
Re: important programming languages (Jeffrey Williams)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Software PRNG..
Date: Thu, 14 Dec 2000 18:16:55 GMT
On Thu, 14 Dec 2000 12:40:52 +0100, in
<[EMAIL PROTECTED]>, in sci.crypt Jorgen Hedlund
<[EMAIL PROTECTED]> wrote:
>"John A. Malley" wrote:
>>
>> Jorgen Hedlund wrote:
>> [snip]
>>
>> > Where could I catch on this kind of theory?
>>
>> Begin with introductory probability and statistics texts, such as
>
><snip>
>
>Woa... Ok, thanks.. I'll get back here in a couple of years then ;)
You could do worse than to examine the basic statistics definitions in
my Glossary, e.g.:
http://www.io.com/~ritter/GLOSSARY.HTM#Statistics
http://www.io.com/~ritter/GLOSSARY.HTM#Distribution
each of which has many links to related terms.
If you have trouble with this material, I would be interested in
knowing what, if anything, could be done to improve the material for
someone like you.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: Michael Erskine <[EMAIL PROTECTED]>
Subject: Re: important programming languages
Date: Thu, 14 Dec 2000 13:14:39 -0500
Tim Tyler wrote:
> I don't think you can call Perl an interpreted language any more.
> It still works from plain text files - but employs all sorts of
> cleverness and intermediate representations during execution.
> It does not wade through the original text as a scripting
> language would.
If one MUST make the distinction between interpreted and compiled, the one
most commonly accepted in computer science puts a (sort of) dotted line at the
hardware. Compiling is best defined as processing a description of an
algorithm one time and generating a binary which can be interpreted many
times. Interpretation is best defined as processing tokens which represent an
algorythm in sequence to accomplish that algorythm. Thus machine language is
interpreted by a microprocessor, C is compiled to a binary which is then
interpreted by the microprocessor, and Perl is nearly always interpreted but
sometimes is used to generate C which is then compiled and subsequently
interpreted. Java is run as P-code in the JIT which is interpretation when
viewed at one level and compilation when viewed at another. So are Pascal and
a whole slew of other languages.
Why does it matter? Is the argument about who knows the most or which
language is the best, or precisely what? Are people here to discuss
encryption technology or are you all going to rename the group to
comp.sci.languages?
-m-
> --
> __________ http://alife.co.uk/ http://mandala.co.uk/
> |im |yler [EMAIL PROTECTED] http://hex.org.uk/ http://atoms.org.uk/
--
Nothing astonishes men so much as common sense and plain dealing.
Ralph Waldo Emerson
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: ethical considerations ...
Date: Thu, 14 Dec 2000 12:28:01 -0600
Peter Thorsteinson wrote:
>
> Do there exist any ethical considerations regarding the maintenance of a
> secret? What if such maintenance could potentially do harm to others?
>
> Do there exist any ethical considerations regarding an attack on a secret?
> What if the breach of the secret could potentially do harm to others?
You might want to read a local newspaper. There's got to be *some* kind
of scandle in your neighborhood. It's a scandle because somebody held
something secret from everybody else, and did harm. What's the ethics?
Patience, persistence, truth,
Dr. mike
------------------------------
Reply-To: "Veli-Pekka Nousiainen" <[EMAIL PROTECTED]>
From: "Veli-Pekka Nousiainen" <[EMAIL PROTECTED]>
Crossposted-To: comp.sys.hp48
Subject: Re: KEYEVAL again was - Crypto Program for HP48GX Calculator
Date: Thu, 14 Dec 2000 20:43:00 +0200
Hi, Tom !
I have stumbled here:
<< 2050. MENU 11. 16. FOR k
95.2 KEYEVAL @ { }
k KEYEVAL @ F1...F6 inside the curly brackets
105. KEYEVAL @ press [ENTER] to push it into Stack
HEAD @ get rid of the { }
1. STEP @ here it errors ???
>>
VPN, incapable in may ways...
"Tom St Denis" <[EMAIL PROTECTED]> wrote in message
news:91b1hf$4e2$[EMAIL PROTECTED]...
> In article <91ah7b$ldv$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] wrote:
> > Hi,
> >
> > I am looking for some crypto programs for the HP48GX. I am interested
> in
> > DES and RSA but any other would be good too, the new AES algorithms
> for
> > example.
> >
> > Can anyone help?
>
> Why can't anyone do something for THEMSELVES! Try writting your own
> code and if you get stumped ask for help.
>
> For christ sake is everyone in this newsgroup incapable of their own
> work?
>
> Tom
>
>
> Sent via Deja.com
> http://www.deja.com/
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: Protocol for computer go
Date: 14 Dec 2000 19:02:56 GMT
Reply-To: [EMAIL PROTECTED] (David Wagner)
Francois Grieu wrote:
>Take of a program which plays one of two advise given by 2 process,
>alledgedly depending on which took the less time. If a human, instead
>of speed, decides the best move among the two [...]
Yes. As I said, this is not secure in the sense that cryptographers
are used to. But, for the purposes of ruling out cheating in Big Blue,
I think this countermeasure is sufficient -- IBM is not going to buy
a double-sized supercomputer just to be able to cheat in this way!
Then again, we could argue whether any countermeasure is truly needed.
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: Protocol for computer go
Date: 14 Dec 2000 19:06:29 GMT
Reply-To: [EMAIL PROTECTED] (David Wagner)
There's a simpler solution. A chooses R_A, publishes a commitment
to R_A, stretches R_A to as much randomness is necessary using a stream
cipher, and plays the game. Afterwards, A opens the commitment.
B does the same.
Now each side has secret, verifiable randomness available to it.
If you also need to generate public randomness (e.g., to decide who
goes first), use any bit-flipping protocol (see, e.g., Schneier).
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: Unguessable sequence of unique integers?
Date: Thu, 14 Dec 2000 18:55:52 GMT
John Savard wrote:
> Well, since a cipher with a 32-bit block is vulnerable to a
> chosen-plaintext attack of complexity 2^32, it is 'believed' insecure.
Because even a random permutation of the 2^32 blocks
is a poor data cipher, due to the small-codebook problem.
Here, what we want is a pseudo-random permutation of
32-bit blocks, not a cipher.
> Also, if just a counter is used - as he proposes - as
> input into the block cipher, then the problem is
> serious.
It's essentially counter-mode.
See:
http://csrc.nist.gov/encryption/aes/modes/lipmaa-ctr.pdf
--Bryan
Sent via Deja.com
http://www.deja.com/
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: security by obscurity ...
Date: 14 Dec 2000 19:10:12 GMT
Reply-To: [EMAIL PROTECTED] (David Wagner)
John Myre wrote:
>Using a secret algorithm may be philosophically the same
>as using a secret parameter (key), but the practical
>differences are compelling. Consider, first, the problem
>of the size of the secret. A secret key is quite small,
>compared to a secret algorithm.
In practice, this is often not a good idea. You get a family of
cipher, and if they are sufficiently different, each cipher has to be
independently verified, which is way too much work for the good guys.
And avoiding weak keys is very hard: Unless you're really good, if you
just try to generate random ciphers, probably some fraction of them are
weak, which is not so good. This seems to be not the easiest way I've
ever heard of to design a secure cipher. :-)
------------------------------
From: "Peter Thorsteinson" <[EMAIL PROTECTED]>
Subject: Re: ethical considerations ...
Date: Thu, 14 Dec 2000 19:11:26 GMT
> Maintenance of a secret? You encrypt it once and it's encrypted.
> There is no maintenance.
There better be maintenance! If your secret is not maintained, then you must
have not encrypted it very well.
------------------------------
From: "Peter Thorsteinson" <[EMAIL PROTECTED]>
Subject: Re: security by obscurity ...
Date: Thu, 14 Dec 2000 19:16:35 GMT
> Unless you're really good, if you
> just try to generate random ciphers, probably some fraction of them are
> weak, which is not so good.
The same would go for random keys. Some fraction of them are weak. However,
I see your point. a good algorithm would have a small proportion of keys
that are weak. The problem is that it is not obvious which keys are going to
become weak due to mathematical break throughs in the future.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: ethical considerations ...
Date: Thu, 14 Dec 2000 19:22:16 GMT
On Thu, 14 Dec 2000 16:25:59 GMT, "Peter Thorsteinson"
<[EMAIL PROTECTED]> wrote, in part:
>Do there exist any ethical considerations regarding the maintenance of a
>secret? What if such maintenance could potentially do harm to others?
>Do there exist any ethical considerations regarding an attack on a secret?
>What if the breach of the secret could potentially do harm to others?
Well, of course there are ethical issues in both areas.
But they are connected with what is right and wrong in other areas.
Sometimes it can get complicated, with things like the rules lawyers
abide by, or with issues such as insider trading, but in general it is
not hard to see when information is being withheld to facilitate
causing harm, or obtained without right.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: ethical considerations ...
Date: Thu, 14 Dec 2000 13:37:34 -0600
In article <rw6_5.80938$[EMAIL PROTECTED]>, "Peter
Thorsteinson" <[EMAIL PROTECTED]> wrote:
> Do there exist any ethical considerations regarding the maintenance of a
> secret? What if such maintenance could potentially do harm to others?
Secrets are information owned by someone that is not supposed to
accessible to just anyone. Indeed a secret may not be accessible beyond
the holder at all. The divulging of a secret to another is made for
weighted reasons, including the risk that it may become known to
unintended others. Maintenance of a secret does no harm, it is in other
acts that harm might be done, not mere hearsay.
>
> Do there exist any ethical considerations regarding an attack on a secret?
Some use having a secret as a taunt. The best kept secrets are not hinted
at or acknowledged. Attacking a poorly held secret means that the secret
is held in a manner it should not be, and that it is obvious or feasible
to figure it out may be another secret, or not.
> What if the breach of the secret could potentially do harm to others?
Then, a moral judgement is in order. Best not to share such secrets, nor
beg for them.
--
No one should call themselves moral, certainly not Christian,
when championing the deprivation of anothers simple vote for the
hell of it.
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: security by obscurity ...
Date: 14 Dec 2000 19:54:13 GMT
Reply-To: [EMAIL PROTECTED] (David Wagner)
Peter Thorsteinson wrote:
>The same would go for random keys. Some fraction of them are weak.
No, I think you are missing the point. This is not so if the
underlying cipher structure allows you to evaluate all of them at
the same time.
But, when the goal is to ensure that the keys cause the underlying
algorithm itself to vary substantially, this often seems to make
analysis harder.
Look at FROG if you need an example to make this concrete. There,
the key determined the connection structure: i.e., the avalanche properties
were key-dependent. (This was how FROG ensured that each key created a
different-looking algorithm.) No big surprise, then, that some keys led
to very bad avalanche properties. Voila! Weak keys.
Compare to what FROG would have been like if it had not tried to follow
this goal of ensuring that each key creates a radically different
algorithmic structure. Then, the connection structure (and avalanche
properties) would have been fixed once and for all, and this failure
mode would have been prevented.
------------------------------
From: Paul Rubin <[EMAIL PROTECTED]>
Subject: Re: ethical considerations ...
Date: 14 Dec 2000 11:57:33 -0800
"Peter Thorsteinson" <[EMAIL PROTECTED]> writes:
> Do there exist any ethical considerations regarding the maintenance of a
> secret? What if such maintenance could potentially do harm to others?
>
> Do there exist any ethical considerations regarding an attack on a secret?
> What if the breach of the secret could potentially do harm to others?
Of course there are, but this has nothing to do with cryptography.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Visual Basic Source Code
Date: Thu, 14 Dec 2000 19:13:27 GMT
Tom St Denis <[EMAIL PROTECTED]> wrote:
> In article <91b0mp$3gl$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] wrote:
>> Does anyone know where i can get GOOD source code for MD4, MD5, SHA1,
>> DES, IDEA, and CAST in VB??
> Why is everyone interested in VB? Arrg!
Mainly because it's the largest market for software components
ever. With sufficiently deep pockets, you can procure almost an entire
application for next to nothing.
On the other hand, since you can easily find any of the above in C,
roll them into a .dll and call into that via VB, I have no idea why
everyone's interested in VB ciphers. It's certainly _not_ clear that
the ability to set their parameters via a property sheet at build time
is desireable. Oh look, fill in the blank key field!
--
Matt Gauthier <[EMAIL PROTECTED]>
------------------------------
From: Richard Hutchinson <[EMAIL PROTECTED]>
Crossposted-To: comp.sys.hp48
Subject: Re: Crypto Program for HP48GX Calculator
Date: Thu, 14 Dec 2000 20:02:05 GMT
A real friendly fella.
Tom St Denis wrote:
>
> In article <91ah7b$ldv$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] wrote:
> > Hi,
> >
> > I am looking for some crypto programs for the HP48GX. I am interested
> in
> > DES and RSA but any other would be good too, the new AES algorithms
> for
> > example.
> >
> > Can anyone help?
>
> Why can't anyone do something for THEMSELVES! Try writting your own
> code and if you get stumped ask for help.
>
> For christ sake is everyone in this newsgroup incapable of their own
> work?
>
> Tom
>
> Sent via Deja.com
> http://www.deja.com/
--
Richard Hutchinson
[EMAIL PROTECTED]
------------------------------
From: "Peter Thorsteinson" <[EMAIL PROTECTED]>
Subject: Re: ethical considerations ...
Date: Thu, 14 Dec 2000 20:10:11 GMT
Thanks for your response. However, now that you have persuaded me, I am
puzzled about what your response has to do with cryptography.
------------------------------
From: David Eppstein <[EMAIL PROTECTED]>
Subject: Re: Protocol for computer go
Date: Thu, 14 Dec 2000 12:08:37 -0800
In article <91b5nl$7am$[EMAIL PROTECTED]>, [EMAIL PROTECTED] (David
Wagner) wrote:
> There's a simpler solution. A chooses R_A, publishes a commitment
> to R_A, stretches R_A to as much randomness is necessary using a stream
> cipher, and plays the game. Afterwards, A opens the commitment.
> B does the same.
>
> Now each side has secret, verifiable randomness available to it.
>
> If you also need to generate public randomness (e.g., to decide who
> goes first), use any bit-flipping protocol (see, e.g., Schneier)
The problem is that, in many actual game playing programs, there isn't any
explicit use of random number generators; the nondeterminism comes from
much harder-to-control factors (like, exactly how many positions did the
program have time to consider while waiting for the opponent to move).
--
David Eppstein UC Irvine Dept. of Information & Computer Science
[EMAIL PROTECTED] http://www.ics.uci.edu/~eppstein/
------------------------------
From: [EMAIL PROTECTED]
Subject: discrete math textbook
Date: Thu, 14 Dec 2000 20:11:24 GMT
Can anybody recommend a decent textbook on discrete math? I have
college-level math background (mainly calculus) and want to self-study
some discrete math. It will be good if CS-oriented, but not necessary.
Many thanks,
Neurite
Sent via Deja.com
http://www.deja.com/
------------------------------
From: Simon Johnson <[EMAIL PROTECTED]>
Subject: Re: Visual Basic Source Code
Date: Thu, 14 Dec 2000 20:34:51 GMT
In article <91b151$404$[EMAIL PROTECTED]>,
Tom St Denis <[EMAIL PROTECTED]> wrote:
> In article <91b0mp$3gl$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] wrote:
> > Does anyone know where i can get GOOD source code for MD4, MD5,
SHA1,
> > DES, IDEA, and CAST in VB??
>
> Why is everyone interested in VB? Arrg!
>
> Tom
>
> Sent via Deja.com
> http://www.deja.com/
>
I would say because its faster to code in than C..... However, this is
debatable with cryptographic algorithms since most of the functions
required to make an algorithm are not supported by the language.
Simon.
--
Hi, i'm the signuture virus,
help me spread by copying me into Signiture File
Sent via Deja.com
http://www.deja.com/
------------------------------
From: Simon Johnson <[EMAIL PROTECTED]>
Subject: Re: ethical considerations ...
Date: Thu, 14 Dec 2000 20:31:06 GMT
In article <rw6_5.80938$[EMAIL PROTECTED]>,
"Peter Thorsteinson" <[EMAIL PROTECTED]>
wrote:
> Do there exist any ethical considerations regarding the maintenance
of a
> secret? What if such maintenance could potentially do harm to others?
>
> Do there exist any ethical considerations regarding an attack on a
secret?
> What if the breach of the secret could potentially do harm to others?
>
>
However difficult the ethics is, Human's have a right to privacy.
People often think thoughts which may lead to the harm of others, but
don't persue that notion. If these thoughts are enciphered into, then
ethically this becomes a problem.
The thing to remember is that the encrypted data itself cannot cause
harm to an individual; only the person(s) who know that secret.
Its tricky ethics, i'll give you that. But people generally don't use
cryptography to hide plans of this nature, as tom has already mentioned.
Simon
--
Hi, i'm the signuture virus,
help me spread by copying me into Signiture File
Sent via Deja.com
http://www.deja.com/
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: important programming languages
Date: Thu, 14 Dec 2000 20:04:09 GMT
Michael Erskine wrote:
> Why does it matter? Is the argument about who knows the most or which
> language is the best, or precisely what? Are people here to discuss
> encryption technology or ...
It's the natural consequence of an imprecise question.
*No* widely available programming language is truly
"best" for use in developing cryptologic applications.
"Best" itself requires a metric, and one's choice of
weights for the relevant factors will certainly affect
the evaluation.
For classical cryptanalysis such as the Zendian problem,
I found the classic UNIX tools, augmented by a few small
C programs and shell scripts, to do the job reliably and
conveniently. If a large amount of "crunching" is needed,
then it is easier to justify spending time on developing
faster solutions.
Many tasks would be easier in Icon (for example), *if*
Icon were installed on the necessary system(s). Since
there are costs associated with porting/installing/
maintaining/learning programming languages, it makes
sense to identify the relative utility of them if they
were to be available, then get and use them starting
with the most essential first. I'd put C at the top of
the list, since it *can* be used for nearly any task,
followed by a string-oriented language (Awk, Icon, etc.).
For creating GUIs you might use Visual Basic, Delphi,
TCL/TK, or something like GTK (provided as a C library).
Only if you are employed to produce a product that has
to run as fast as possible would I suggest learning
assembly language (for whatever processor(s) are
involved).
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: On using larger substitutions
Date: Thu, 14 Dec 2000 21:52:19 +0100
Simon Best wrote:
>
> It seems (though I'm not in a position to say for certain) than any
> scheme that makes a bigger S-box out of smaller ones needs more than one
> round to work well. The well known block ciphers (DES, the AES
> finalists, etc) need multiple rounds, for example.
>
> As an idea for how the byte transpositions could be done, I'd like to
> suggest the following:
>
> 1. Take all the bytes with even numbered indices (positions 0, 2, etc,
> in the block) from the old block and put them at the front of the new
> block.
>
> 2. Take all the bytes with odd numbered indices from the old block and
> put them at the back of the new block.
>
> For example:
>
> a0 a1 a2 a3 a4 a5 a6 a7
>
> becomes:
>
> a0 a2 a4 a6 a1 a3 a5 a7
>
> Or:
>
> a0 a1 a2 a3 a4 a5 a6
>
> a0 a2 a4 a6 a1 a3 a5
>
> Just a suggestion!
The best known transposition in classical cryptography
is the columnar transposition. It can be done very easily.
If one could afford to use a PRNG, then a pseudo-random
permutation could be done. (Another method utilizes the
sorting technique.)
M. K. Shen
------------------------------
From: Jeffrey Williams <[EMAIL PROTECTED]>
Subject: Re: important programming languages
Date: Thu, 14 Dec 2000 15:03:51 -0600
Depends on your concept of "commercial". I spent the latter part of the
90's writing (new) code for a telephone switch (in current use) in Z8000
assembler. I spent the latter part of the 80's writing (new) code for
the military in assembler.
I do agree that, percentagewise, assembler coding counts for very
little, but I suspect that most folks would be surprised at how much
still occurs.
Personally, I'd much rather see a few critical parts coded in assembler
with the remainder done in something rather higher level. Even in
embedded apps, most code is just not time-critical enough to warrant
coding in assembler.
Jeff
"Douglas A. Gwyn" wrote:
> On a modern RISC processor, it requires an extremely high
> degree of skill to implement an algorithm in assembly
> language with a faster result than would result from using
> the C compiler provided by the processor manufacturer.
> It is certainly easier to maintain and port source code
> that is written (with reasonable care) in C. Almost no
> commercial applications are coded in assembler these days,
> even if they only target Intel x86 processors; there is a
> lot more to programming than simply getting a specific
> machine to execute an algorithm one time, and the wider
> economics of software development are not well served by
> excessive use of assembly language.
>
> There are a *few* circumstances in which a *small* portion
> of an application will execute inefficiently in a higher-
> level language, and if these bottlenecks are of sufficient
> concern then it will justify coding *just the bottleneck
> operations* in assembler in such a way that it can be
> invoked from the rest of the application that is coded in
> the HLL, but even so it still makes sense to maintain the
> reference implementation in the HLL (for porting,
> verification, and understanding in the maintenance cycle).
------------------------------
** 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
******************************
