Cryptography-Digest Digest #372, Volume #11 Mon, 20 Mar 00 19:13:02 EST
Contents:
Re: hardware errors (Samuel Paik)
Re: The Breaking of Cyber Patrol® 4 (Jerry Coffin)
Re: Download Random Number Generator from Ciphile Software (Anton Stiglic)
Re: hardware errors (Mok-Kong Shen)
Re: The Breaking of Cyber Patrol® 4 ([EMAIL PROTECTED])
Re: DES Decryption Problem (James Muir)
Re: The Breaking of Cyber Patrol® 4 (Troed)
Re: The Breaking of Cyber Patrol® 4 (Ichinin)
Re: The Breaking of Cyber Patrol® 4 (Ichinin)
implementing rot13 (Arthur Dardia)
Re: Card shuffling ("Douglas A. Gwyn")
Re: The Breaking of Cyber =?US-ASCII?Q?Patrol=AE?= 4 (David A Molnar)
Re: The Breaking of Cyber =?iso-8859-1?Q?Patrol=AE?= 4 ("Trevor L. Jackson, III")
Re: implementing rot13 ("Douglas A. Gwyn")
IV vs. SALT? ("Marc Howe")
Re: Quantum crypto flawed agains Mallory? ([EMAIL PROTECTED])
Re: Download Random Number Generator from Ciphile Software (Taneli Huuskonen)
Re: implementing rot13 (Stephen Houchen)
Re: Download Random Number Generator from Ciphile Software (Doug Stell)
Re: encryption and decryption with elliptic curve cryptography (Scott Contini)
Re: Factorization (David Hopwood)
Re: PC-1, anyone ? ("Adam Durana")
----------------------------------------------------------------------------
From: Samuel Paik <[EMAIL PROTECTED]>
Subject: Re: hardware errors
Date: Mon, 20 Mar 2000 21:18:13 GMT
Mok-Kong Shen wrote:
> What is the rate that a defective chip passes
> through the production controls? (It is known that even design
> errors sometimes occured and escaped sophisticated systems aimed
> to help the design engineers to ensure correctness.)
EVERY complex chip design I know of in some detail had design errors.
--
Samuel S. Paik | http://www.webnexus.com/users/paik/
3D and multimedia, architecture and implementation
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: The Breaking of Cyber Patrol® 4
Date: Mon, 20 Mar 2000 14:21:17 -0700
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
says...
> Ichinin <[EMAIL PROTECTED]> wrote, in part:
>
> >How does bypassing a complete program affect copyright, from what i've
> >heard the program only allow you to _bypass_ cyber patrol - _not_ copy
> >it.
>
> Well, copyright requires you to accept the license agreement, the
> license agreement can forbid reverse engineering...
Rather the contrary -- at least in the US, copyright law and license
agreements are largely mutually exclusive, and courts have held that
reverse-engineering copyrighted code is perfectly legal.
Even if the license agreement, rather than copyright law, was held to
cover a particular case, that doesn't necessarily mean that the
license agreement would be completely upheld: the law is quite
specific in saying that "unconscionable" items in license agreements
won't be upheld (among other limitations).
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
From: Anton Stiglic <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: Download Random Number Generator from Ciphile Software
Date: Mon, 20 Mar 2000 16:23:16 -0500
Is there a Paper that goes along with this implementation of a
Random Number Generator. Something that describes why
it is cryptographicaly safe, some scientific reasoning to
convince myself why I should think about using it?
Anton
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: hardware errors
Date: Mon, 20 Mar 2000 22:39:14 +0100
wtshaw wrote:
>
> I remember a time when a whole shipment of 7490's would break into divide
> by 8 instead of 10 above not too hot a temperature. As them were used to
> sync clock rates at both ends of a system, when the complementary fair
> both failed, the problem seemed to go away as they synced again....really
> drove us up the wall for a while.
>
> We were curious how these chips ever made it out of the factory in
> Salvador. The answer was that if we wanted good testing, buy mil spec.
> But, they did replace the chips, recall the lot, etc. Good testing never
> shows up as a defective practive, but it does tend to be a necessary cost.
The temperature factor you pointed out is worth noting. I suppose
we probably generally have some natural tendency to underestimate
the problem of possible mal-functioning of the chip we are using,
simply because we mostly don't have the knowledge/facility to do
checks and also can't have the checks done by a third party with
reasonable cost. Compare this, say, with one's car. So in a state
of hopelessness, we unconsciously take the strategy to neglect the
problem. Fairly long ago, one of my acquaintances who did much
low-level programming told me that he found a bug in 80xx and
reported it to the manufacturer but failed to get an answer. The
problem was later 'solved' in a natural way: the hardware was
replaced as a more advanced series of the same manufacturer without
the bug became available. It may thus seem advisable that (in case
multiple hardware could be afforded) one employs hardware of
different architectures, if that is possible.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: The Breaking of Cyber Patrol® 4
Date: 20 Mar 2000 21:39:00 GMT
In a previous article, <[EMAIL PROTECTED]> writes:
>I'm in Sweden, and I'm quite positive I'm allowed to reverse engineer
>anything I want to.
Forget that. You're not.
You should read the Swedish law "Lag (1960:729) om upphovsrätt till litterära
och konstnärliga verk", articles 26 g § and 26 h §.
----- Posted via NewsOne.Net: Free Usenet News via the Web -----
----- http://newsone.net/ -- Discussions on every subject. -----
NewsOne.Net prohibits users from posting spam. If this or other posts
made through NewsOne.Net violate posting guidelines, email [EMAIL PROTECTED]
------------------------------
From: James Muir <[EMAIL PROTECTED]>
Subject: Re: DES Decryption Problem
Date: Mon, 20 Mar 2000 21:38:10 GMT
> I suspect your encryption process has a bug. You should check it
> against test vectors. Check that:
>
> DES_encrypt ( 4e6f772069732074 ) = 3fa40e8a984d4815
when the key is K = 0123456789abcdef
-James
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Troed)
Subject: Re: The Breaking of Cyber Patrol® 4
Reply-To: [EMAIL PROTECTED]
Date: Mon, 20 Mar 2000 22:05:56 GMT
[EMAIL PROTECTED] wrote:
>>I'm in Sweden, and I'm quite positive I'm allowed to reverse engineer
>>anything I want to.
>
>Forget that. You're not.
>
>You should read the Swedish law "Lag (1960:729) om upphovsrätt till litterära
>och konstnärliga verk", articles 26 g § and 26 h §.
... which you so nicely sent me, and which I still think proves me
right :)
Again, which court decision has said otherwise?
Note: I've only said I can _reverse engineer_ anything I like to, I
have _not_ said anything about spreading knowledge gained from that.
___/
_/
------------------------------
From: Ichinin <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: The Breaking of Cyber Patrol® 4
Date: Fri, 17 Mar 2000 23:50:15 +0100
Troed wrote:
> I'm in Sweden, and I'm quite positive I'm allowed to reverse engineer
> anything I want to.
Correct, the .SE copyright law (1960:729, paragraph 26, Subnote H (I
think it's "H", Anyway i'm 100% sure that it's under Paragraph 26))
says that any agreements that prevents you from doing that is void.
------------------------------
From: Ichinin <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: The Breaking of Cyber Patrol® 4
Date: Sat, 18 Mar 2000 00:06:56 +0100
Troed wrote:
> ... which you so nicely sent me, and which I still think proves me
> right :)
>
> Again, which court decision has said otherwise?
>
> Note: I've only said I can _reverse engineer_ anything I like to, I
> have _not_ said anything about spreading knowledge gained from that.
Reverse engineering for a) fixing bugs and b)compatibility is enough.
For personal (non illegal/commercial) use [Generic] "anything goes"
[/Generic]
It makes you think on *what* you are revealing before you bloat out
insecurities in systems. I know of 2 ways of downing a popular Network
OS, i'm not sure if i should report these security bugs i know of or
keep them in my head to stay away from suits.
Again: Do anyone have any info on the trial or hearings on this matter?
Best regards,
Glenn
Sweden
------------------------------
From: Arthur Dardia <[EMAIL PROTECTED]>
Subject: implementing rot13
Date: Mon, 20 Mar 2000 17:34:14 -0500
I know this isn't the place to ask this; however, I'm having problems
implementing a ROTXX function, where XX is an integer from 1-26, albeit
26 would be useless, that would perform, ironically...ROT-13 upon a
string if the string and 13 are passed to it. I think I'm just being
retarded, but here's what I have:
apstring rotXX(apstring target,int xx) {
apstring uRef="ABCDEFGHIJKLMNOPQRSTUVWXYZ";
apstring lRef="abcdefghijklmnopqrstuvwxyz";
for (int i=0;i<uRef.length();i++) {
for (int a=0;a<target.length();a++) {
if (target[a]==uRef[i]) {
target[a]=uRef[(i+xx)%25];
}
}
}
for (i=0;i<lRef.length();i++) {
for (int a=0;a<target.length();a++) {
if (target[a]==lRef[i]) {
target[a]=lRef[(i+xx)%25];
}
}
}
return target;
}
I'll admit it is a crappy, round-about way of coding, but don't yell at
me...:)
Here's the output of this debug statement:
cout << "key--: " << key << endl;
cout << "rot13: " << rotXX(key,13) << endl;
yields
key:? abcdefghijklmnopqrstuvwxyz
rot13: bcdefghijklmabcdefghijklmn
As you can see, if I input a test key and attempt to ROT-13 it, the
second half of the key (n->z) is properly rot-13'd; however, the first
half is not. What's going on?
--
Arthur Dardia Wayne Hills High School [EMAIL PROTECTED]
PGP 6.5.1 Public Key http://www.webspan.net/~ahdiii/ahdiii.asc
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Card shuffling
Date: Mon, 20 Mar 2000 22:49:22 GMT
Mok-Kong Shen wrote:
> ... I conjecture that one should apply
> additional filtering to check that there are not patterns (or
> the like since I have never played card games and am hence
> ignorant) that could render the session undesirable in one
> sense or the other.
It is *important to the game* that all possible patterns be
allowed. In Poker, one wants to be able to be dealt an
occasional royal flush! In Bridge, one wants to be able
to win a grand slam on occasion! And so forth. The games
would be dreadfully dull if only thoroughly out-of-sequence
patterns were allowed in the shuffled deck.
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: The Breaking of Cyber =?US-ASCII?Q?Patrol=AE?= 4
Date: 20 Mar 2000 22:59:33 GMT
Ichinin <[EMAIL PROTECTED]> wrote:
> insecurities in systems. I know of 2 ways of downing a popular Network
> OS, i'm not sure if i should report these security bugs i know of or
> keep them in my head to stay away from suits.
Report them via an anonymous remailer ?
Thanks,
-David
------------------------------
Date: Mon, 20 Mar 2000 18:14:37 -0500
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: The Breaking of Cyber =?iso-8859-1?Q?Patrol=AE?= 4
John Savard wrote:
> Well, copyright requires you to accept the license agreement, the
> license agreement can forbid reverse engineering...
I believe this to be incorrect. The terms of sale may require that all requirements
of the license agreement be met, but the copyright laws do not (AFAIK) influence one's
acceptance of the license terms. Software licensing terms have recently been a hot
topic in the UCC area, but I think that's unrelated to copyright.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: implementing rot13
Date: Mon, 20 Mar 2000 23:06:28 GMT
Arthur Dardia wrote:
> As you can see, if I input a test key and attempt to ROT-13 it, the
> second half of the key (n->z) is properly rot-13'd; however, the first
> half is not. What's going on?
I don't know, but n->z aren't properly ROT13ed either.
The modulus should be 26, not 25.
------------------------------
From: "Marc Howe" <[EMAIL PROTECTED]>
Subject: IV vs. SALT?
Date: Mon, 20 Mar 2000 23:07:54 GMT
I'm a newbie to crypto, so I was wondering what the differences (if any -
and similarities as well) are between IV (Initialization Vector) and SALT?
Thank you,
Marc
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Quantum crypto flawed agains Mallory?
Date: Mon, 20 Mar 2000 22:55:54 GMT
In article <8b62no$tmg$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
>
> > Then Alice and Bob compare their measurements publicly. This is
> > the step that foils the man-in-the-middle. If comparison of each
> > photon pair which is caputured matches, then there's no way any
> > of the photons were disturbed. If the photons were disturbed, then
> > Bob's measurements wouldn't match at all with Alice's, and they
> > would know an active attack was in progress.
>
> Sure, but you just described the regular Quantum protocol.
Correct. The above paragraph does not
describe the new and alternative Mitra
protocol.
> Besides this, knowing that you are being attacked does not diminish
> the problem: your enemy may have the message (or part, like my other
> post) anyway.
>
You might be interested to know that it is now
possible for an attacker to gain part or all of
the encrypted quantum data yet *not* be able
to derive any info about the original quantum
state. This security is enabled via the brand
new quantum one time pad:
http://arxiv.org/abs/quant-ph/0003059
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Taneli Huuskonen)
Crossposted-To: talk.politics.crypto
Subject: Re: Download Random Number Generator from Ciphile Software
Date: 21 Mar 2000 01:07:04 +0200
=====BEGIN PGP SIGNED MESSAGE=====
In <NjoB4.48416$[EMAIL PROTECTED]> "Tom St Denis"
<[EMAIL PROTECTED]> writes:
>What is the period of the generator?
If I understand the documentation right, it's of the order of (10!)^2,
which should be large enough for most purposes. However, there is a
flaw in the algorithm that makes it definitely unsuitable for serious
cryptographic purposes and might affect its use for large-scale
simulation too. Basically, the generator first initializes three arrays
of 10! permutations of 0..9 each. Denote the i'th permutations in these
arrays by a_i, b_i and c_i, respectively. Then, on round i, the
generator produces the number c_i (b_i (c_i (a_i (i mod 10)))), when
0 <= i < 10! . When k * 10! <= i < (k+1) * 10!, the permutations
a_{(i+k) mod 10!}, b_{i mod 10!} and c_{i mod 10!} are used instead.
If one had access to the raw digit stream, there would be a rather
trivial way to break the code, given maybe a couple hundred million
known digits - the only thing that changes between round i and
round i+10! is the permutation a_i. However, these digits are
transformed into a stream of bytes by grouping them into triplets,
dividing by 3 and discarding anything exceeding 255. This makes it more
difficult to attack the cipher, possibly preventing an amateur such as
myself from breaking it.
Taneli Huuskonen
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQB1AwUBONavAQUw3ir1nvhZAQF7aAL8C5E9CiPZ2+R09U36x/0/KeQguoUqFnqZ
7Dj1Tee71DYpgpf+VwczxnlHuIPWH2wfzc4hlywCxbRVHvZUTXFHjm39LrlMlNw2
7OqJrJUtv1by6PlIELUbGAKmpBzNH9fi
=nq2d
=====END PGP SIGNATURE=====
--
I don't | All messages will be PGP signed, | Fight for your right to
speak for | encrypted mail preferred. Keys: | use sealed envelopes.
the Uni. | http://www.helsinki.fi/~huuskone/ | http://www.gilc.org/
------------------------------
From: Stephen Houchen <[EMAIL PROTECTED]>
Subject: Re: implementing rot13
Date: Mon, 20 Mar 2000 17:20:35 -0600
Arthur Dardia wrote:
> I know this isn't the place to ask this; however, I'm having problems
> implementing a ROTXX function, where XX is an integer from 1-26, albeit
> 26 would be useless, that would perform, ironically...ROT-13 upon a
> string if the string and 13 are passed to it. I think I'm just being
> retarded, but here's what I have:
>
> apstring rotXX(apstring target,int xx) {
> apstring uRef="ABCDEFGHIJKLMNOPQRSTUVWXYZ";
> apstring lRef="abcdefghijklmnopqrstuvwxyz";
>
> for (int i=0;i<uRef.length();i++) {
> for (int a=0;a<target.length();a++) {
> if (target[a]==uRef[i]) {
> target[a]=uRef[(i+xx)%25];
> }
> }
> }
>
> for (i=0;i<lRef.length();i++) {
> for (int a=0;a<target.length();a++) {
> if (target[a]==lRef[i]) {
> target[a]=lRef[(i+xx)%25];
> }
> }
> }
>
> return target;
>
> }
>
> I'll admit it is a crappy, round-about way of coding, but don't yell at
> me...:)
> Here's the output of this debug statement:
>
> cout << "key--: " << key << endl;
> cout << "rot13: " << rotXX(key,13) << endl;
>
> yields
>
> key:? abcdefghijklmnopqrstuvwxyz
> rot13: bcdefghijklmabcdefghijklmn
>
> As you can see, if I input a test key and attempt to ROT-13 it, the
> second half of the key (n->z) is properly rot-13'd; however, the first
> half is not. What's going on?
You're changing some letters twice. Notice your second for-loop pair.
You first change the 'a' to 'n' correctly, but instead of going on to the
next character, you change the 'n' back to an 'a' before going on.
S
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Doug Stell)
Crossposted-To: talk.politics.crypto
Subject: Re: Download Random Number Generator from Ciphile Software
Date: Mon, 20 Mar 2000 23:14:17 GMT
On Mon, 20 Mar 2000 01:31:15 -0800, Anthony Stephen Szopa
<[EMAIL PROTECTED]> wrote:
>Again, OAR-L3 random number generation software is only intended to
>generate random digits or numbers for statistical modeling and computer
>simulations.
This statement is a very clear hint that it is not cryptographically
strong and is of little use to anybody in this newsgroup. If it is a
component of a larger cryptographic package, this statement also casts
sersiou doubt on the strength of that package.
------------------------------
From: [EMAIL PROTECTED] (Scott Contini)
Subject: Re: encryption and decryption with elliptic curve cryptography
Date: 20 Mar 2000 23:54:12 GMT
In article <ojoB4.48415$[EMAIL PROTECTED]>,
Tom St Denis <[EMAIL PROTECTED]> wrote:
>
>kingtim <[EMAIL PROTECTED]> wrote in message
>news:[EMAIL PROTECTED]...
>> Please tell me simply how to do encryption and decryption with elliptic
>> curve cryptography.
>> and any web site about this topic.
>>
>
>It's not a simple topic at all. Try reading some books, confusing yourself,
>and hope for the best.
>
>Tom
>
>
Elliptic curve cryptosystems are not that complicated if you
look at them the right way (from an abstract algebra perspective).
The general idea can work in any group. Start by learning the
basics of elliptic curves - understand that they form a group,
and be able to derive the laws for point addition and doubling.
Learning how to apply them to cryptography is not that difficult
once you've accomplished this first step.
The best place to learn about elliptic curve cryptography is
Certicom's web site:
http://www.certicom.com/ecc/enter/index.htm
A great book for an introduction to elliptic curves is ``Rational
Points on Elliptic Curves'' by Tate/Silverman.
Scott
------------------------------
Date: Mon, 20 Mar 2000 22:19:05 +0000
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Factorization
=====BEGIN PGP SIGNED MESSAGE=====
Scott Fluhrer wrote:
[...]
> The integers is a Unique Factorization Domain, which is a fancy way of
> saying that any integer can be factored into primes in essentially one way.
That reminds me: are there any PK cryptosystems based on the hardness of
factoring in UFDs other than the integers? Also, is there any reason to
believe that factoring in a different, suitably chosen UFD could be harder
than factoring integers?
- --
David Hopwood <[EMAIL PROTECTED]>
PGP public key: http://www.users.zetnet.co.uk/hopwood/public.asc
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBONajwzkCAxeYt5gVAQGpmQgAqBg7Bu19h0T/IS/8/tlhURah6EhhE2Pt
gnCbjTyc42yQpE2QUT7Jv+eC5Pa1N647O31m5XDhlI3DYcwypKZ3N62yTIRQw0nu
h/KlUwKYsxbxaHOB71mHkx834lIa8tY24gkldR7lQSxqwwSKaXKJjMvoIvUjgeMs
B7Ol3D2TI7PIV+cVAbM+ce+8e0TNmPwdBvr4nBjhR/V5kMUBWbTSLyXX6/aD7Qh8
+OLp8uBe3wd/4EMmzsxHOh3IX2VRpRPipE2MBxz9ZHEcSPH6I4tsXuwbASyhsbMl
Mv6OiJPyHp9fCcebazlbVS/So+u5MCzC7l9O5e2nCfhdra8l86S2Fw==
=kYli
=====END PGP SIGNATURE=====
------------------------------
From: "Adam Durana" <[EMAIL PROTECTED]>
Subject: Re: PC-1, anyone ?
Date: Mon, 20 Mar 2000 19:09:40 -0500
The name Alexander Pukall rings a bell. I remember him doing a lot of
posting about encryption software he had supposedly been able to break. I
say supposedly because I seem to remember most of his claims being
inconclusive or false altogether. This is all from memory so don't quote me
on that. Perhaps you should search on a service such as deja.com that keeps
track of everyone's postings for a long period of time. (Even if they don't
use deja.com to post)
- Adam
"Christoph Weber-Fahr" <[EMAIL PROTECTED]> wrote in message
news:8b5afo$ist$[EMAIL PROTECTED]...
> Hi,
>
> in a project I stumbled upon a piece of software using
> Alexander Pukall's PC1 (Pukall Cipher 1).
>
> I'm trying to form an opinion on this. Abusing deja to some degree I found
> a number of hints vaguely linking it to RC4, but nothing precise.
>
> So....
>
> - has anybody ever eard of it ? Should it be considered serious ?
> - is it actually a RC4 implementation ?
> - is there any kind of analysis somebody could point me to ?
>
> I'd be grateful for any hint .
>
>
> Regards, and thanks in advance,
>
> Christoph Weber-Fahr
>
>
> --
> Christoph Weber-Fahr | E-Mail: [EMAIL PROTECTED]
> -------------------------- My personal opinion
y ---------------------
------------------------------
** 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
******************************
