Cryptography-Digest Digest #913, Volume #12 Fri, 13 Oct 00 18:13:00 EDT
Contents:
Re: Triple DES versus Rijndael (John Myre)
Re: Rijndael implementations (John Myre)
Re: ANNOUNCE: SandMark -- A Software Watermarking Tool for Java (Tom St Denis)
Sending the same messgae twice -- why is this a weakness? ("David C. Barber")
Re: My SHA code and Endianess (Tom St Denis)
Re: Comments on the AES winner (wtshaw)
Re: Crypto technology recommendations? (David A Molnar)
Re: Sending the same messgae twice -- why is this a weakness? (David Schwartz)
Re: ANNOUNCE: SandMark -- A Software Watermarking Tool for Java (Bjorn Luser)
Re: ANNOUNCE: SandMark -- A Software Watermarking Tool for Java (David Schwartz)
Re: random number sequences (Mok-Kong Shen)
Re: ANNOUNCE: SandMark -- A Software Watermarking Tool for Java (Andru Luvisi)
Re: Refutation-- I think. (Stas Busygin)
Numeric conversion algorithm needed. (Jon DeCamp)
Re: Is it trivial for NSA to crack these ciphers? (lcs Mixmaster Remailer)
Re: Is it trivial for NSA to crack these ciphers? (David Schwartz)
Re: Rijndael implementations ("Douglas A. Gwyn")
Re: FTL Computation (Wayne Throop)
Re: A new paper claiming P=NP (Stas Busygin)
----------------------------------------------------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: Triple DES versus Rijndael
Date: Fri, 13 Oct 2000 13:18:49 -0600
ajd wrote:
>
> Excuse the ignorance but what is a FIPS?
(U.S.) Federal Information Processing Standard
See http://csrc.nist.gov/fips/ etc.
JM
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: Rijndael implementations
Date: Fri, 13 Oct 2000 13:16:08 -0600
"Douglas A. Gwyn" wrote:
>
> jungle wrote:
> > these usages are now obsolete.
>
> Correct use of technical terminology is never obsolete.
> "Automobile" does not connote "4 wheels" even if all
> 3-wheeled models are currently out of production.
Agree, agree - except that I think you should have
said "denote", since the connotation certainly is
4 wheels. "Correct connotation" is almost oxymoronic.
JM
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Crossposted-To: comp.security.misc,comp.lang.java.security,comp.lang.java.programmer
Subject: Re: ANNOUNCE: SandMark -- A Software Watermarking Tool for Java
Date: Fri, 13 Oct 2000 19:23:57 GMT
In article <8s7iq1$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Christian S. Collberg) wrote:
>
> SandMark: Software Watermarking for Java
> ----------------------------------------
>
> The first version of SandMark, a software watermarking
> tool for Java, is now available for download:
>
> http://www.cs.arizona.edu/sandmark/
>
> SandMark is a system for embedding a watermark in a Java program.
> It modifies the application source code to make it build a
> heap-based structure at execution time that encodes a watermark.
> The watermark is recognized by dumping and analyzing the Java heap.
>
> SandMark embodies the research described in
>
> Software Watermarking: Models and Dynamic Embeddings,
> by Christian Collberg and Clark Thomborson, published in
> ACM Symposium on Principles of Programming Languages (POPL99)
>
http://www.cs.auckland.ac.nz/~collberg/Research/Publications/CollbergTho
mborson99a
>
> SandMark was implemented by Gregg Townsend and Christian Collberg
> at the University of Arizona, under NSF grant CCR-0073483.
Wow...
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "David C. Barber" <[EMAIL PROTECTED]>
Subject: Sending the same messgae twice -- why is this a weakness?
Date: Fri, 13 Oct 2000 12:31:06 -0700
Quoting from: http://www.eclipse.net/~dhamer/lorenz.htm
---
...the Lorenz SZ40/42.
The first real break into Tunny traffic occurred on August 30, 1941 when a
cipher clerk in Vienna sent a long message - four thousand or so
characters - to his opposite number in Athens. When he had finished this
formidable typing effort he received a reply which was the German equivalent
of "I didn't get all that. Please send it again..!". So he did - using,
against all established principles of cipher security, the same machine
settings that he had used for the first transmission. He also used a number
of abbreviations [e.g. 'Spruchnummer' became 'Spruchnr' , etc.]. This
egregious error was the chance for which BP was waiting and a team headed by
Colonel John Tiltman deciphered the message in short order.
---
This may be really dumb, but why was this a weakness? If the operator sent
the same message twice using the same settings each time, the second message
should have been a duplicate of the first message, and offered no additional
information any more than if someone had written the message twice. Was the
problem that the second message was only similar, not identical?
*David Barber*
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: My SHA code and Endianess
Date: Fri, 13 Oct 2000 19:35:44 GMT
In article <[EMAIL PROTECTED]>,
Ed Kubaitis <[EMAIL PROTECTED]> wrote:
> Tom St Denis wrote:
> >
> > I have a strange feeling my code is not as "endian neutral" as I
> > wanted. Can someone on a big endian please test it out? This is
> > driving me mad...
> >
> > http://www.geocities.com/tomstdenis/files/sha256.c
> >
> > Tom
> > ...
>
> Same output for a few files I tried on a Sun Ultra 2300 as
> on a Pentium III. One of them was a ~280e6 byte compressed
> tar file. If there were an endian problem, it would have
> to be pretty subtle.
You mean 280^6 or 164070 bytes? I would think it works then :-)
> By the way, compiled with a simple -O on both platforms
> it got a little under 8e6 bytes/cpu-second on a 500 MHz
> PIII, and a little over 3e6 bytes/cpu-second on the
> 300 MHz UltraSPARC.
Well it's example code, I suspect numerous trivial optimizations are
possible. Thanks for testing it.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Comments on the AES winner
Date: Fri, 13 Oct 2000 13:28:04 -0600
In article <8s63ba$qa4$[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
> Luckily all AES
> candidates are interchangeable as a consequence of NIST's
> specifications. (In fact, it would be a good idea if future designs of
> new ciphers would follow these specifications.)
>
Convenience is in the mouse of the beholder. Considering one list of
specifications adequate belies the point that differences are the crux of
questions of security of each, and certain aspects of security might be
contrary to the list of specifications.
--
Production technology goes wrong when the producers do not
understand the users. --Patrick Whitney
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: Crypto technology recommendations?
Date: 13 Oct 2000 19:50:37 GMT
DJohn37050 <[EMAIL PROTECTED]> wrote:
> I think there are many many ways to go wrong by trying to do it yourself.
> Consider getting a toolkit from a crypto provider. Certicom has Security
> Builder, RSA has BSAFE, and others have them.
> Don Johnson
Don't forget OpenSSL - http://www.openssl.org/
it has a learning curve, though. rather annoying one at that.
-david
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: Sending the same messgae twice -- why is this a weakness?
Date: Fri, 13 Oct 2000 12:57:09 -0700
"David C. Barber" wrote:
> This may be really dumb, but why was this a weakness? If the operator sent
> the same message twice using the same settings each time, the second message
> should have been a duplicate of the first message, and offered no additional
> information any more than if someone had written the message twice. Was the
> problem that the second message was only similar, not identical?
Yes, that was the problem.
As a gross oversimplification, consider a substitution cipher where
each letter is replaced with another letter. If the same message is sent
twice, but once with the sequence 'you' and again with the sequence 'u'
instead, just having these two encrypted texts, you would immediately
break three letters.
The same thing happens analogously in more complex ciphers. Some
signature algorithms, for example, can be compromised if you can get
someone to sign the same message enough times. Designing ciphers to
resist this type of situation is important.
For more information, search for the phrase 'related plaintext attack'.
DS
------------------------------
From: Bjorn Luser <[EMAIL PROTECTED]>
Crossposted-To: comp.security.misc,comp.lang.java.security,comp.lang.java.programmer
Subject: Re: ANNOUNCE: SandMark -- A Software Watermarking Tool for Java
Date: Fri, 13 Oct 2000 19:59:08 GMT
Nice idea. Too bad you applied for a software patent for it.
Software patents are inherently evil. Use copyright protection
instead.
In article <8s7iq1$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Christian S. Collberg) wrote:
>
> SandMark: Software Watermarking for Java
> ----------------------------------------
>
> The first version of SandMark, a software watermarking
> tool for Java, is now available for download:
>
> http://www.cs.arizona.edu/sandmark/
>
> SandMark is a system for embedding a watermark in a Java program.
> It modifies the application source code to make it build a
> heap-based structure at execution time that encodes a watermark.
> The watermark is recognized by dumping and analyzing the Java heap.
>
> SandMark embodies the research described in
>
> Software Watermarking: Models and Dynamic Embeddings,
> by Christian Collberg and Clark Thomborson, published in
> ACM Symposium on Principles of Programming Languages (POPL99)
>
http://www.cs.auckland.ac.nz/~collberg/Research/Publications/CollbergTho
mborson99a
>
> SandMark was implemented by Gregg Townsend and Christian Collberg
> at the University of Arizona, under NSF grant CCR-0073483.
>
> Christian Collberg
> Department of Computer Science
> The University fo Arizona
>
--
... and this time, I mean it!
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: ANNOUNCE: SandMark -- A Software Watermarking Tool for Java
Date: Fri, 13 Oct 2000 13:35:15 -0700
Bjorn Luser wrote:
>
> Nice idea. Too bad you applied for a software patent for it.
>
> Software patents are inherently evil. Use copyright protection
> instead.
Please keep the political commentary off of sci.crypt.
DS
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: random number sequences
Date: Fri, 13 Oct 2000 23:13:32 +0200
Pete wrote:
> say i generate a keystream using say, RC4. i presume this could be
> viewed as a stream of bytes(or a vector space over B ??). how would i
> got about converting this number stream to a different base ?
>
> if i were wanting to have a random stream of numbers in say base 27 for
> example, could i just 'mod 27' the original keystream or would that
> mangle the statistical properties of the keystream ?
If the bit stream is uniform, taking 5 bits and mod 27
wouldn't get you a uniform result, but you can discard
values greater than 26. This wastes somewhat. If you don't
like that, see the post of Herman Rubin of 30th Sep in
the thread 'Question on biases in random-numbers & decompression'.
M. K. Shen
------------------------------
From: Andru Luvisi <[EMAIL PROTECTED]>
Subject: Re: ANNOUNCE: SandMark -- A Software Watermarking Tool for Java
Date: 13 Oct 2000 13:50:18 -0700
David Schwartz <[EMAIL PROTECTED]> writes:
[snip]
> Please keep the political commentary off of sci.crypt.
[snip]
Unfortunately, political issues have a great deal to do with
cryptography. A technology that cannot be used due to export issues,
government restrictions on cryptographic products, or patents becomes
less useful to the community as a whole. As long as these issues
effect the use of cryptography, they will be a large part of the
discussion that goes on here.
Once there are no more patents, export controls, or laws limiting the
use of cryptography, you may find your request granted. Until then,
such subjects are very much on topic.
Andru
--
Andru Luvisi, Programmer/Analyst
Quote Of The Moment:
"The player who believes he cannot be decieved is in great danger. The
knowledge that no one is safe is his best protection."
- S. W. Erdnase
------------------------------
From: Stas Busygin <[EMAIL PROTECTED]>
Crossposted-To: comp.theory,sci.math,sci.op-research
Subject: Re: Refutation-- I think.
Date: Sat, 14 Oct 2000 00:20:58 +0300
Hi Eric!
This is a fault in the definition of D(G). The author has corrected
it. Instead of
|In general case we can construct a set $D(G)$ of different acyclic
digraphs
|as it is indicated above. Each digraph of $D(G)$ corresponds to
|the graph $G\in L_{n}$. Further we will consider only digraphs of
$D(G)$.
he writes
|In general case we can construct a set $D(G)$ of different acyclic
digraphs
|each of which is generated by some orientation of edges of the
graph
|$G\in L_{n}$. Further we will consider only digraphs of $D(G)$.
That is, D(G) is the set of *all* acyclic digraphs obtainable from
the original graph G by directing its edges.
The patched file of the paper is already uploaded to
http://www.geocities.com/st_busygin/clipat.html
Thank you very much for your participation!
Best regards,
Stas Busygin
email: [EMAIL PROTECTED]
WWW: http://www.busygin.dp.ua
Eric Lehman wrote:
>
> Theorem 2 on page 10 of Plotnikov's P = NP paper is *FALSE*.
> (snip)
------------------------------
From: Jon DeCamp <[EMAIL PROTECTED]>
Subject: Numeric conversion algorithm needed.
Date: Fri, 13 Oct 2000 21:32:41 GMT
Greetings,
I've got some data that seems fairly encrypted, and I thought this would
be a great place to ask about it. I have a list of 11 digit numbers and
I am told that they *somehow* convert to six digit numbers.
I have posted (below) some of the 11 digit numbers as well as the six
digit numbers that they convert to. I do have, however, a whole lot
more 11 digit numbers and have no idea how to convert them. Some advice
would be much appreciated.
15903077074 322704
15904377681 212349
15904347451 134537
15904389746 612905
17905206616 682427
15905248944 459661
17905214530 722899
15904345215 147771
15905266611 212978
15904766325 950946
15901866138 103097
15902873075 579719
15904337781 927047
15904397596 796855
Thanks in advance,
-Jon
------------------------------
Date: 13 Oct 2000 21:40:08 -0000
From: lcs Mixmaster Remailer <[EMAIL PROTECTED]>
Subject: Re: Is it trivial for NSA to crack these ciphers?
> But a good cryptographic algorithm is not a car. For some reason people
>seem to attribute wizard-like powers to these agencies. Modern algorithms are
>subjected to public scrutiny in an environment where the secret agencies have no
>advantage (public disclosure of algorithms and attacks). With modern cryptography
>the NSA is no better off than anyone else. Where the opponents fall down are
>in the more prosaic aspects of security: key distribution and human factors. I
>think it can be said that despite the paranoia of some, the algorithms of modern
>crypto themselves are safe from NSA (or any other alphabet soup agency) attack.
>Securing the channel itself is not the problem. Securing the endpoints and the
>key distribution path as well as guaranteeing the loyalty of the
>participants is what usually is the biggest problem for those who come into
>conflict with the alphabet soup agencies. Of course, the truly paranoid might
>say that worrying about the algorithm is what the NSA wants you to do. The old
>"Look here not there" is the oldest trick in the spy's arsenal. Most of the
>really brilliant spying is covered up with misdirection, just like the
>magicians do. There is no such thing as wizardry, only misdirected attention.
Aren't you forgetting the obvious fact that these "alphabet soup agencies" don't use
any of these ciphers to conceal data that is important to them?
And overall, the U.S. government seems to have loosened up crypto restrictions. Call
this FUD if you want, but I find it hard to believe these controls were relaxed
because either:
A) The genie was already out of the bottle
B) American software companies were finally successful in convincing the government
that they were loosing business to overseas companies.
C) The original policy was just plain stupid, and the government changed to to look
smart(er).
I suppose one could assert the "not invented here" philosophy as the primary reason
the government uses secret ciphers to contain secret data.
But no one disputes that there are genuine cryptography experts at Ft. Meade that
believe their ciphers are the best and most secure in the world.
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: Is it trivial for NSA to crack these ciphers?
Date: Fri, 13 Oct 2000 14:47:51 -0700
lcs Mixmaster Remailer wrote:
> Aren't you forgetting the obvious fact that these "alphabet soup agencies" don't use
>any
> of these ciphers to conceal data that is important to them?
Different problems get different solutions. It's really that simple.
In any event, political arguments like this really don't belong on
sci.crypt. Take this to talk.politics.crypto.
DS
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Rijndael implementations
Date: Fri, 13 Oct 2000 20:37:03 GMT
"SCOTT19U.ZIP_GUY" wrote:
> I worked with field data characters 6 bits and 9 bit ascii
> on machines that had 36 bit words. But I would say 8 bits is what
> is normally meant by a BYTE in todays world.
It depends on context. "Byte" means one thing when used in
describing modern disk or RAM hardware, another thing when
talking about the official specs for the C programming
language, and yet another thing in its original use (from
which the others evolved) in talking about contiguous
portions of a machine word. The only one of these that is
necessarily bound to 8 bits (by convention) is the first
one, describing current disk or RAM capacity. In other
contexts, there is no presumption of 8 bits, and to make
such a presumption is to make an error.
------------------------------
From: [EMAIL PROTECTED] (Wayne Throop)
Crossposted-To: sci.astro,sci.physics.relativity,sci.math
Subject: Re: FTL Computation
Date: Fri, 13 Oct 2000 21:50:52 GMT
: ca314159 <[EMAIL PROTECTED]>
: A double standard ? That sounds like a slide rule to me. :)
:
: Sure, the I/O is not FTL.
: But where is the computation taking place ?
Simple. The computation takes place where there is a causal connection
between successive states as you slide the rule. There is no causal
connection between successive states of the projected image, so the
computation isn't "going on" in the projected (expanded, and hence FTL) image.
As I say, simple.
: but then, [.. a projected point ..] itself becomes sort of a fuzzy,
: half-real, illusion of a quantum-like entity.
Nonsense. It doesn't become vaue, nor fuzzy, nor does it have anything
to do with, or any features connected with, "quantum-like entities".
It's simple. The successive states (and positions) of a projected image
aren't caused by the previous states (at the previous positions) of that
image. Therefore, it doesn't represent transfer of information, nor
does it represent a computation.
As I say, simple. Straightforward. No problem whatsoever.
Wayne Throop [EMAIL PROTECTED] http://sheol.org/throopw
"He's not just a Galaxy Ranger... he's a Super-Trooper!"
------------------------------
From: Stas Busygin <[EMAIL PROTECTED]>
Crossposted-To: comp.theory,sci.math,sci.op-research
Subject: Re: A new paper claiming P=NP
Date: Sat, 14 Oct 2000 01:14:38 +0300
Hi Jeff!
Jeff Erickson wrote:
>
> Stas Busygin <[EMAIL PROTECTED]> writes:
> | According to the publishing rules of my *REPOSITORY* any stuff in it
> | can be renewed at any time, so all found faults are to be corrected
> | by authors. That is why I think my publishing policy makes sense --
> | anyone who wishes can become familiar with proposed stuff in its raw
> | form and help authors to correct/improve it.
>
> Electronic preprint repositories have a definite place, but based on
> my swift glance at the paper and the posted reactions of other
> readers, I think it was not polished enough to be a preprint.
>
> Perhaps this was merely an English language problem. If that's the
> case, publish the paper in Russian. There must be a few Russian
> mathematicians and computer scientists who can validate his results!
Ok, let's consider this case to be my fault. Next time, I'll
translate submitted Russian papers by myself and then verify the
translation with at least one person, whose first language is
English. Let me beg for mercy of the community.
> Ultimately, it is the author's reponsibility to write clean, clear,
> correct papers. It is not the research community's reponsibility to
> decipher unreadable drafts or to fix the author's bugs.
Nobody is forced to pay any attention to the stuff I publish.
Please feel free to ignore it if you think that it's not
appropriate for your consideration. However, I think it will be
very useful if the promotion helps authors to find volunteer able
to help them.
> | Personally I think that an algorithmic proposal has a great chance
> | to be outdated for such term if its field develops appropriately...
>
> Huh? Outdated??? It took two years for Wiles' and Taylor's proof to
> be accepted. What's the rush?
I'm talking about innovative efficient *algorithms*. Whenever such
an algorithm is obtained and its correctness is verified for at
least some instances considered to be hard previously, I think it
is time to give it publicity. There may be other people working on
related issues who will be able to comprehend it from their own
viewpoint and introduce the next level of improvements. When we are
talking about an algorithm, its idea is more important than a proof
as it may be applied for a bunch of related problems... And online
forums in the net can be utilized widely for that purpose...
Best regards,
Stas Busygin
email: [EMAIL PROTECTED]
WWW: http://www.busygin.dp.ua
------------------------------
** 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 (and sci.crypt) via:
Internet: [EMAIL PROTECTED]
End of Cryptography-Digest Digest
******************************
