Cryptography-Digest Digest #260, Volume #10 Fri, 17 Sep 99 23:13:02 EDT
Contents:
crypto papers (Tom St Denis)
Re: (US) Administration Updates Encryption Export Policy ("rosi")
Re: Ritter's paper ([EMAIL PROTECTED])
Re: Ritter's paper ("Trevor Jackson, III")
Re: Analogues to ECC over higher dim. abelian varieties (Alex)
Re:peekboo needs help :( (Tom St Denis)
Re: NSA and MS windows ("Trevor Jackson, III")
Re: SCOTT19U.ZIP_GUY/Questions Please ("Trevor Jackson, III")
Re: Okay "experts," how do you do it? ("Trevor Jackson, III")
Re: NSA and MS windows (Eric Lee Green)
Re: How does RC5 work? ("Trevor Jackson, III")
Re: Okay "experts," how do you do it? (David Wagner)
Re: NSA and MS windows (Jerry Coffin)
----------------------------------------------------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: crypto papers
Date: Sat, 18 Sep 1999 01:06:52 GMT
In the spirit of sharing information here is a list of all the relevant
crypto papers and such I have... if you want any email me at
[EMAIL PROTECTED]
16 round differential cryptanalysis of DES.ps 990414-mrobshaw.pdf
aes-comment-to-nist.ps AES ciphers on the 6805.pdf A faster attack on certain
stream ciphers.ps A fast new hash function - TIGER.ps All or Nothing
Disclosure of Secrets.ps Analysis of Splaying.ps Analysis of the sboxes in
DES.ps A new kind of stream cipher CHAMELEON.ps An Implementation of the
Number Field Sieve.ps asiacrypt98-slides-c.ps BellareRivest-translucent.ps
Blowfish Constants.pdf bsa-final-report.txt
BurmesterRivestShamir-geometric.ps card_cipher.ps CAST-256 AES Submission.ps
CFB_mode_of_DES.pdf chaffing-980701.txt chaotic.ps Chapter 6 - Stream Ciphers
(CRC press).ps Chapter 7 - Block Ciphers (CRC press).pdf Chapter 14 -
Efficient Implementations of Algorithms (CRC press).ps Chapter 2 - Math
Background (CRC press).ps Chapter 5 - Pseudo Random Bit Generators.ps Cipher
Block Chaining.ps clipper.txt Correlations in RC6.ps cramer-shoup public
key.pdf crc faq.pdf CRC Press (Applied Crypto) Block Ciphers.ps Cryptanalysis
of Blowfish.ps Cryptanalysis of FROG.pdf Cryptanalysis of MAGENTA.pdf
Cryptanalysis of loki89.ps Cryptanalysis of TWOPRIME.pdf Cryptanalysis of
loki91.ps Cryptanalysis of MD5.ps Cryptanalysis of ICE.ps Cryptanalysis of
RC5.ps Cryptanalysis of Lok97.ps Cryptanalysis of Lucifer.ps Cryptanalysis of
CMEA.ps crypto4n2.pdf Cryptographic File Systems.ps Crypton V1.0 AES
Submission.ps Cryptanalysis of SKIPJACK (impossible differentials).ps
Cryptanalysis of ORYX.ps DEAL AES Submission.pdf design-vulnerabilities.pdf
DFC AES Submission.ps DFC AES Submission (update).ps DFC for smartcards.ps
diehard.zip Differential Cryptanalysis of FEAL and N-HASH.ps Differential
Cryptanalysis of DES-like systems.ps Differential Cryptanalysis of IDEA.ps
Differential Cryptanalysis of Kafre, Loki, REDOC .ps Differential
Cryptanalysis of SAFER.ps diffusion in the AES candidates.pdf discrete
logratihms in finite fields and their cryptographic significance.pdf E2 AES
Submission.pdf Elements of Linear and Abstract Algebra.ps Elliptic Curve
Cryptography Faq.pdf encryption tutorial (part 1).pdf fast new des.ps
fast_software_encryption.pdf feistel networks.pdf fibonacci generators.ps
Formal Treatment of remote key encryption.ps FROG AES Submission.pdf
GoldmanRivest-MakingMaximumEntropyComputationsEasierByAddingExtraConstraints.
ps How to forge DES messages in {2^28} steps.ps How to protect DES against
exhaustive key search DESX.ps How to strengthen DES using existing
hardware.ps hpc-over.pdf hpc-spec.pdf hpc-subm.pdf IDEACrypt_Coprocessor.pdf
IDEACrypt_Kernel.pdf Key Schedule Cryptanalysis PART ONE.pdf Key Schedule
Cryptanalysis PART TWO.ps khufu.tar.gz Links between linear and differential
analysis.ps list.txt LOKI97 AES Submission.ps lottery.pdf Magenta AES
Submission.pdf MARS AES Submission.pdf Master Key Cryptosystems.ps mod n
analysis.pdf multi-permutations.ps observation of key schedule (TwoFish).pdf
On Modes of operations.ps on the construction of variable-input-length
ciphers.ps On the Number Field Sieve.ps On the security of the CS-Cipher.ps
On the security of Quantum Cryptography against Collective Attacks.ps
Parallel FFT-Hashing.ps pentum optimizations.txt personal-entropy.pdf
Proth.ini Provably secure one-way hash functions.ps Provable Security using
Decorrelatiion.ps provably secure and efficient block ciphers.ps pseudo1
(frobenius primes).ps pseudorandom_number.pdf quasi.ps r1report.pdf Random
Bit Generators using smoke_detectors.ps ranno.ps rc2-fse.ps rc4_revealed.txt
RC4_TEST.txt rc6-notes.txt RC6 AES Submission.ps realrandomnum.txt related
key cryptanalysis.ps Rijndael.pdf
Rivest-GameTreeSearchingByMinMaxApproximation.ps Rivest-MD5.pdf
RivestShamirWagner-timelock.ps Rivest-MD4.pdf rivest-factoring.txt rsa129.pdf
RSA Algorithm - A method for obtaining digital signatures and public key
cryptography.ps RSA evalutation of RC5.pdf RSALABS Faq.pdf rsa on MD
algorithms.pdf RSA ROUND ONE.pdf safer.pdf safer key schedule.pdf
SAFERPPT.pdf sbox generation for TIGER.ps schneier-talk.pdf sciam98.txt
seal.ps Searching for ultimate correlation (Stream Ciphers).ps sec2_1.ps
sec2_3.ps sec2_4.ps sec2_6.ps sec2_7.ps security.ps Security of MacGuffin
(Thesis).ps self-study course in cryptanalysis.pdf SERPENT AES Submission.ps
SHA-0 Collisions.ps simon_sh.ps skipjack-1.pdf snefru.c sol.c sol.exe Sorting
Out Zero Knowledge.ps speed-sac.pdf square.pdf ssl-challenge.txt
street_performer.pdf tests.txt The AKELARRE block cipher.ps The bit
extraction problem or t-Resilient functions.ps The BLOWFISH block cipher.pdf
The Boomerang Attack.ps The CAST-128 block cipher.pdf The CRISP block
cipher.ps The CS block cipher.pdf The ICE block cipher.ps The IDEA block
cipher.ps The LOKI91 block cipher.ps The LOKI89 block cipher.ps The MacGuffin
block cipher.ps The RC5 block cipher.ps The Security of Cryptographic
Primitives.ps The Slide Attack.ps The TEA block cipher.ps The XTEA block
cipher.ps Three Xor-Lemmas.ps tis_walker_export_101293_hr.txt turtle.ps
Twinkle RSA factoring device.ps Twofish AES Submission.pdf
twofish-reference-c.zip twofish-optimized-c.zip twofish-assem.zip vp.txt Why
Cryptosystems Fail.ps Word Autokey Cipher (WAKE).ps WS_FTP.LOG xmx a firmware
oriented block cipher.ps xormacs.ps xxtea.ps yarrow-full.pdf
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: "rosi" <[EMAIL PROTECTED]>
Subject: Re: (US) Administration Updates Encryption Export Policy
Date: Fri, 17 Sep 1999 21:52:24 -0400
Dear Helger,
Thanks for the update.
Read some kind of an abstract, but it did not have the explicit 'license
exception'. One thing I read is that 'approval' is a one time thing and not
a
case-by-case saga. So if I understand 'correctly' that except the special
conditions, e.g. to certain terrorist countries, it is a 'technical review'
to go
through. You mentioned 64-bit, does that mean that anything under 64-bit
is an ok-to-go? Or it is still limited to a list of them, such as DES? What
I
read did not mention a key-size restraint (but what I read is very cursory
and
for general audience). Sorry so many questions. (Went to the pointer you
provided but did not see the publication)
As the other asked: How is this 'technical review' defined and on what
basis can one application be turned down?
Thanks
--- (My Signature)
Helger Lipmaa wrote in message <[EMAIL PROTECTED]>...
>FYI
>Helger Lipmaa
>http://home.cyber.ee/helger
>-------------------------------------------------
>
>
http://www.pub.whitehouse.gov/uri-res/I2R?urn:pdi://oma.eop.gov.us/1999/9/1
>
>6/15.text.1
>
>THE WHITE HOUSE
>
> Office of the Press Secretary
>________________________________________________________________________
>
>For Immediate Release September 16, 1999
>
> FACT SHEET
>
> Administration Updates Encryption Export Policy
>
>Today, the Clinton Administration announced a new approach to encryption
>
>policy that includes updates and simplifies export controls. The major
>components of this update are as follows:
>
>Global exports to individuals, commercial firms or other
>non-governmental entities
>
>Any encryption commodity or software of any key length can now be
>exported under a license exception (i.e., without a license) after a
>technical review, to commercial firms and other non-government end users
>
>in any country except for the seven state supporters of terrorism.
>Exports previously allowed only for a company's internal use can now be
>used for communication with other firms, supply chains and customers.
>Additionally, telecommunication and Internet service providers may use
>any encryption commodity or software to provide services to commercial
>firms and non-government end users. Previous liberalizations for banks,
>
>financial institutions and other approved sectors are subsumed under
>this Update. Exports to governments can be approved under a license.
>
>Global exports of retail products
>
>Retail encryption commodities and software of any key length may be
>exported under a license exception (i.e., without a license) after a
>technical review, to any recipient in any country except to the seven
>state supporters of terrorism. Retail encryption commodities and
>software are those products which do not require substantial support for
>
>installation and use and which are sold in tangible form through
>independent retail outlets, or products in tangible or intangible form,
>which have been specifically designed for individual consumer use.
>There is no restriction on the use of these products. Additionally,
>telecommunication and Internet service providers may use retail
>encryption commodities and software to provide services to any
>recipient.
>
>Implementation of the December 1998 Wassenaar Arrangement Revisions
>
>Last year, the Wassenaar Arrangement (33 countries which have common
>controls on exports, including encryption) made a number of changes to
>modernize multilateral encryption controls. As part of this update, the
>
>U.S. will allow exports without a license of 56 bits DES and equivalent
>products, including toolkits and chips, to all users and destinations
>(except the seven state supporters of terrorism) after a technical
>review. Encryption commodities and software with key lengths of 64-bits
>
>or less which meet the mass market requirements of Wassenaar's new
>cryptographic note will also be eligible for export without a license
>after a technical review.
>
>U.S. Subsidiaries
>
>Foreign nationals working in the United States no longer need an export
>license to work for U.S. firms on encryption. This extends the policy
>adopted in last year's update, which allowed foreign nationals to work
>for foreign subsidiaries of U.S. firms under a license exception (i.e.,
>without a license).
>
>Export Reporting
>
>Post-export reporting will now be required for any export to a non-U.S.
>entity of any product above 64 bits. Reporting helps ensure compliance
>with our regulations and allows us to reduce licensing requirements.
>The reporting requirements will be streamlined to reflect business
>models and practices, and will be based on what companies normally
>collect. We intend to consult with industry on how best to implement
>this part of the update.
>
> ###
>
>
>
>
>
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Ritter's paper
Date: Sat, 18 Sep 1999 02:02:56 GMT
Terry Ritter wrote:
[...]
> *I* who can afford to lose a few: I have exponentially many, you
> know.
Could you clarify: in what parameter is the number of
ciphers increasing exponentially? The one such
function I see is that the number of composite ciphers
increases exponentially in the number we compose, as
long as we have two or more from which to choose. But
I don't think that parameter will get very large.
--Bryan
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
Date: Fri, 17 Sep 1999 22:23:54 -0400
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Ritter's paper
Jerry Leichter wrote:
> "I've made the assumption that the "utility function" we want
> to minimize is the expected amount of compromised traffic. This is
> probably an unrealistic assumption, but let's make it for the moment."
>
> Actually, I believe this is the crux of much of your disagreement with
> Mr. Ritter. You're looking at expectations - average values. For
> expections, I believe your arguments are correct.
>
> However, we must also consider what is effectively "the probability of
> ruin". If AES is broken, every message sent using it is broken, and a
> major - potentially immense - investment must be made to completely
> replace an infrastructure based on it. On the other hand, even if a
> significant fraction of Mr. Ritter's individual ciphers are broken, many
> messages remain secure - and in a reasonable design for the infra-
> structure, it's possible to eliminate the bad ciphers from future use
> without rebuilding the entire infrastructure.
>
> Another way of looking at this is that the cost function is highly
> non-linear: As long a reasonably large fraction of Mr. Ritter's ciphers
> are secure, the costs (in broken messages, in the effort needed to weed
> out ciphers that have proven to be weak) are small. The cost grows very
> rapidly beyond a certain point, where most combinations are breakable.
> The problem with an AES, of course, is that there's only one "combina-
> tion", so you get right to the extremely high cost range.
>
> Ignoring the probability of ruin is at the heart of many bad probabilis-
> tic arguments - e.g., many naive arguments about martingales, and all
> sorts of bad investment strategies in the real world.
If choosing siphers is a game we should consider using the min-max
approach. It states that we want to minimize the maximum damage that the
opponent can do to us. In this regard several strong ciphers look vastly
better than one universal cipher no matter how much "better" it is.
Are 1000 ciphers better than (say) 10? There's no single answer to that
question that will satisfy the majority of the readers of thie NG. IHMHO,
the answer is yes.
> On the other hand, I think there are practical difficulties with Mr.
> Ritter's approach. Even the cryptanalytic attacks known in the public
> literature are sufficiently powerful to slice right through most simple
> designs. The ciphers that can survive *even the attacks we know about*
> are pretty rare on the ground. Where will we find a large collection of
> reasonably secure ciphers to use for Mr. Ritter's scheme?
>
> Mr. Ritter likes to design parameterized families of ciphers - a
> powerful approach, and probably the only way to get a large number of
> reasonable cipher designs in hand quickly. But that opens the door to
> attacks against whole families.
>
> If the collection of ciphers to be used in this scheme is fixed up
> front, it will be subject to attack - and likely many ciphers will be
> picked off. So there will likely have to be a mechanism to add new
> ciphers to the mix. However, that opens a powerful line of attack to a
> knowledgeable opponent: He can contribute (through apparently unrelated
> 3rd parties, of course) a large number of apparently very good ciphers
> that he knows how to break. Since no one will be in a position to do
> really deep analyses of many different ciphers, it's unlikely that the
> "spiked" ciphers will be found: It took many years to become convinced
> that DES doesn't have a trap door, and even today there are people who
> retain their suspicions. (Actually, an attacker of this sort wouldn't
> even have to wait for updates: He would likely be right there at the
> initiation of the system, offering up a whole load of neat-looking
> ciphers. It would require a big leap beyond the publically-known state
> of the art in cryptography to slip a trap door into a system like AES,
> which will be very closely examined by many people *and is expected to
> be really strong* - so any weakness that *is* found will immediately
> raise a red flag. On the other hand, it would be relatively easy to
> slip many subtly spiked systems into Mr. Ritter's pool, since no one
> would look at them very closely - and, besides, even if one, or many, of
> the "spikes" were found, how could you distinguish that from those
> ciphers just being weak because the person who proposed them wasn't
> quite as good at crypto as he thought?)
There's a countervailing argument to this in that every compromised cipher
raises the risk of exposure of the person submitting trojans. Every strong
cipher submitted to camoflage the compromised ones reduces the benefit of
the compromised ones by dilution.
In a large scale implementation of large numbers of ciphers we _expect_ some
to be revealed as weak. Since such a revelation is expected, we'll simply
deal with it and move on. Given layers of ciphers around each message the
actual amount of compromised traffic may be very small.
Finally the risk to the trojan submitter is extremely large if the submitter
has a reputation. If the submitter has no reputation (proxy submission)
there is no reason to fear widespread adoption of a large number of flawed
ciphers.
------------------------------
From: Alex <[EMAIL PROTECTED]>
Subject: Re: Analogues to ECC over higher dim. abelian varieties
Date: 17 Sep 1999 22:36:32 -0400
Hi, Robert.
Thanks for the helpful followup. I have a couple more questions, if you
have the time.
Why do you choose a plane quintic to represent your genus two curve? I
had started to look at Jacobians for genus two curves, but I was
planning to use nodal quartics.
Also, are there any good papers to read introducing key techniques for
studying Jacobians over a finite field? My background is complex
algebraic geometry, to the extant that it's anything.
At the moment, I don't see why the points on the Jacobian over a given
finite field are closed under addition. In other words, if C is a plane
nodal quartic in P^2(F_p), and points on the Jacobian are represented in
the form a+b-2*O, then you have linear equivalences of the form
(a+b-2*O)+(c+d-2*O)=(e+f-2*O)
where e and f are points on C extended over the algebraic closure of
F_p. However it is not clear to me why they also have to lie in
P^2(F_p) when a,b,c and d do.
My plan for studying this question was to represent the curve as a nodal
quartic, consider the linear system of quadrics passing through the
node, hope for a point on the curve which appears with multiplicity six
in some divisor of the system, call that O, and then add the points in
roughly the same way you add points on an elliptic curve, i.e., by
finding the quadric that passes through a,b,c,d, and the node, and
letting defining the other two points that the quadric intersects the
quartic in to be -(e+f). Is this how you do additions in the Jacobian
in your computations?
Thanks again.
Alex.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re:peekboo needs help :(
Date: Sat, 18 Sep 1999 01:43:33 GMT
In article <[EMAIL PROTECTED]>,
Anonymous <[EMAIL PROTECTED]> wrote:
> >It supports RC5/Cast/Blowfish/RC4 and
> >Twofish (good varierty)
>
> For a really good *variety* add Leapfrog or Diamond2
> (not designed by the cabal!)
Hmm... well I dunno I am trying to stick with well known algorithms.
If you have some easy to use source (see the source of peekboo) I could add
it in, but I am not re-writing a cipher to use ...
Tom
--
damn windows... new PGP key!!!
http://people.goplay.com/tomstdenis/key.pgp
(this time I have a backup of the secret key)
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
Date: Fri, 17 Sep 1999 22:43:25 -0400
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: NSA and MS windows
> > In <[EMAIL PROTECTED]> fungus <[EMAIL PROTECTED]>
>writes:
> >
> > Well, MS also claimed to have lost the source code to DOS, which I would
> > think was an even harder thing to do.
What subpoena were they responding to when they made this claim? Think it will show
up years
later in the living quarters?
------------------------------
Date: Fri, 17 Sep 1999 21:53:44 -0400
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: SCOTT19U.ZIP_GUY/Questions Please
Douglas A. Gwyn wrote:
> "SCOTT19U.ZIP_GUY" wrote:
> > ... Of course the evidence if there was any was destroyed unless the
> > texas rangers can provide a link.
>
> The evidence from the Branch Davidian fiasco that I'm most interesting
> in determining the fate of is the main entrance door, which seems from
> the scanty remaining evidence to have had *inbound* bullet holes.
> Funny that the FBI could lose something so big. Almost as funny as
> their staging a commando-style raid on a fortified compound instead
"fortified"? I think that's a media exaggeration.
> of knocking politely at the door or interviewing DK when he was out
> of the compound. But not as funny as one of the assailants shooting
> himself in the leg while scaling the building.
The existence of missing audio tapes may be the rest of the evidentiary
iceberg. As I understand it the Justice Dept is claiming that there are
only a few tapes of 19-Apr-93. I wonder how many they have of the days
prior to the final assault? The gap may be hard to explain.
------------------------------
Date: Fri, 17 Sep 1999 21:32:47 -0400
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Okay "experts," how do you do it?
David Wagner wrote:
> In article <[EMAIL PROTECTED]>,
> Sundial Services <[EMAIL PROTECTED]> wrote:
> > Or, to
> > put it another way, let's figure out what exactly it is that makes Bruce
> > Scheirer's opinion better than anyone else's besides the fact that he's
> > written a book.
>
> The whole point of the scientific process is that you _don't_ have
> to trust Schneier's opinion any more than anyone else's. If someone
> has a practical attack, it doesn't matter who he is, or whether he
> is an expert; we can immediately conclude that the cipher is insecure.
I think he's complaining about the other side of the coin. The one where lack
of practical attacks is taken as an indicator that the cipher is secure. That
is not a scientific process.
------------------------------
From: Eric Lee Green <[EMAIL PROTECTED]>
Subject: Re: NSA and MS windows
Date: Fri, 17 Sep 1999 18:07:49 -0700
Jerry Coffin wrote:
> In article <7rr8ar$e53$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
> says...
> > In <[EMAIL PROTECTED]> fungus <[EMAIL PROTECTED]>
>writes:
> >
> > >Tell me, how does a multinational corporation "lose" a key?
> >
> > Well, MS also claimed to have lost the source code to DOS, which I would
> > think was an even harder thing to do.
>
> Where and when has MS claimed any such thing?
It wasn't DOS, it was the source code to the Korean version of Windows
3.1 that Microsoft claims to have lost the source code for.
Caldera, the current owners of DRDOS, inherited the lawsuit where
Microsoft is accused of predatory practices that killed DRDOS. Part of
Caldera's argument is that the Korean release version of Windows 3.1
contained deliberate code that would cause it to fail when run on top of
DRDOS. Microsoft claims that they no longer have the source code to that
version of Windows and thus cannot produce it for the court. Caldera, in
response, has issued a "bounty" for any Korean version of Windows that
contains the "die if under DR-DOS" code.
I don't follow that lawsuit very often (basically just when Caldera
issues a press release, the word "Linux" gets it past my filters), but
in that particular case Microsoft's lawyers definitely did claim that
they'd lost the source code for the program in question (Windows 3.1
though, not DOS).
--
Eric Lee Green http://members.tripod.com/e_l_green
mail: [EMAIL PROTECTED]
^^^^^^^ Burdening Microsoft with SPAM!
------------------------------
Date: Fri, 17 Sep 1999 22:41:27 -0400
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: How does RC5 work?
[EMAIL PROTECTED] wrote:
> <<<SNIP>>>
>
> I have the RC5 source code. I am not a 'C' programmer but to me it
> appears that this code is not the same as the spec. The spec says that
> that <<< means to rotate left, A=((A XOR B) <<< B) + S[2*1]
>
> The 'C' code seems to just shift left.
> #define ROTL(x,y) (((x << (y&(w-1)))
>
> if << in 'C' rotate or shift?
In 'C' << is shift not rotate. If you are using a PC compiler look for
functions lrotl() and lrotr() which perform rotation on longs I believe.
>
>
> Also, I am confused when RSA says that + is two's compliment addition.
> Do I worry about this becuase it is handled by the complier.
>
> > BTW checkout RC5's cool source if you want some good info.
> >
> > ---
> > /* RC5REF.C -- Reference implementation of RC5-32/12/16 in C.
> */
> > /* Copyright (C) 1995 RSA Data Security, Inc.
> */
> > typedef unsigned long WORD; /* Should be 32-bit = 4 bytes
> > */
> > #define w 32 /* word size in bits
> */
> > #define r 12 /* number of rounds
> */
> > #define b 16 /* number of bytes in key
> */
> > #define c 4 /* number words in key = ceil(8*b/w)
> */
> > #define t 26 /* size of table S = 2*(r+1) words
> */
> > WORD S[t]; /* expanded key table
> */
> > WORD P = 0xb7e15163, Q = 0x9e3779b9; /* magic constants
> */
> > /* Rotation operators. x must be unsigned, to get logical right
> shift*/
> > #define ROTL(x,y) (((x)<<(y&(w-1))) | ((x)>>(w-(y&(w-1)))))
> > #define ROTR(x,y) (((x)>>(y&(w-1))) | ((x)<<(w-(y&(w-1)))))
> >
> > void RC5_ENCRYPT(WORD *pt, WORD *ct) /* 2 WORD input pt/output ct
> */
> > { WORD i, A=pt[0]+S[0], B=pt[1]+S[1];
> > for (i=1; i<=r; i++)
> > { A = ROTL(A^B,B)+S[2*i];
> > B = ROTL(B^A,A)+S[2*i+1];
> > }
> > ct[0] = A; ct[1] = B;
> > }
> >
> > void RC5_DECRYPT(WORD *ct, WORD *pt) /* 2 WORD input ct/output pt
> */
> > { WORD i, B=ct[1], A=ct[0];
> > for (i=r; i>0; i--)
> > { B = ROTR(B-S[2*i+1],A)^A;
> > A = ROTR(A-S[2*i],B)^B;
> > }
> > pt[1] = B-S[1]; pt[0] = A-S[0];
> > }
> >
> > void RC5_SETUP(unsigned char *K) /* secret input key K[0...b-1]
> */
> > { WORD i, j, k, u=w/8, A, B, L[c];
> > /* Initialize L, then S, then mix key into S */
> > for (i=b-1,L[c-1]=0; i!=-1; i--) L[i/u] = (L[i/u]<<8)+K[i];
> > for (S[0]=P,i=1; i<t; i++) S[i] = S[i-1]+Q;
> > for (A=B=i=j=k=0; k<3*t; k++,i=(i+1)%t,j=(j+1)%c) /* 3*t > 3*c */
> > { A = S[i] = ROTL(S[i]+(A+B),3);
> > B = L[j] = ROTL(L[j]+(A+B),(A+B));
> > }
> > }
> > ---
> > Tom
> > --
> > PGP 6.5.1 Key
> > http://mypage.goplay.com/tomstdenis/key.pgp
> > PGP 2.6.2 Key
> > http://mypage.goplay.com/tomstdenis/key_rsa.pgp
> >
> > Sent via Deja.com http://www.deja.com/
> > Share what you know. Learn what you don't.
> >
>
> Sent via Deja.com http://www.deja.com/
> Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: Okay "experts," how do you do it?
Date: 17 Sep 1999 19:31:10 -0700
In article <[EMAIL PROTECTED]>,
Trevor Jackson, III <[EMAIL PROTECTED]> wrote:
> I think he's complaining about the other side of the coin. The one where lack
> of practical attacks is taken as an indicator that the cipher is secure. That
> is not a scientific process.
I'm lost: What does this have to do with the definition of "expert"?
After all, the lack of published attacks in the open literature is an
objective fact that doesn't depend on who you choose to call "expert".
------------------------------
From: [EMAIL PROTECTED] (Jerry Coffin)
Subject: Re: NSA and MS windows
Date: Fri, 17 Sep 1999 21:05:55 -0600
In article
<[EMAIL PROTECTED]>,
[EMAIL PROTECTED] says...
[ ... ]
> It wasn't DOS, it was the source code to the Korean version of Windows
> 3.1 that Microsoft claims to have lost the source code for.
That starts to sound at least a _little_ more believable.
> Caldera, the current owners of DRDOS, inherited the lawsuit where
> Microsoft is accused of predatory practices that killed DRDOS. Part of
> Caldera's argument is that the Korean release version of Windows 3.1
> contained deliberate code that would cause it to fail when run on top of
> DRDOS. Microsoft claims that they no longer have the source code to that
> version of Windows and thus cannot produce it for the court. Caldera, in
> response, has issued a "bounty" for any Korean version of Windows that
> contains the "die if under DR-DOS" code.
Hmm...this is rather an odd situation -- the AARD code (at least in
the US version of Windows) was used in the beta version of Windows.
The code remained in the release version, but was disabled. I guess
that I could believe that after passing all regression tests, MS might
toss the various intermediate versions out of their source code
control, and therefore wouldn't be able to produce source to every
beta version.
OTOH, I'm a bit lost as to why they'd particularly care about the
Korean version of Windows, when this code was verified to work in the
US beta version, and was still present (though, as mentioned above,
disabled) in the US release version. Is Caldera's claim that in the
Korean version of Win3.1 that the AARD code was left enabled, even in
the release version?
--
Later,
Jerry.
The Universe is a figment of its own imagination.
------------------------------
** 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
******************************
