Cryptography-Digest Digest #60, Volume #11 Sun, 6 Feb 00 18:13:01 EST
Contents:
Re: need help with a basic C++ algorithm ("Adrian DuChant")
Re: NIST, AES at RSA conference (David Wagner)
Re: Merkle hash tree patent expired (Darren New)
Re: permission to do crypto research ("Roger Schlafly")
Re: ([EMAIL PROTECTED])
Re: NIST, AES at RSA conference (Terry Ritter)
Re: New to cryptology question, rolling XOR (Tim Tyler)
Re: Combining LFSR's (Mok-Kong Shen)
Re: Scaleable Key Permutation Feature ("C. Prichard")
Re: NIST, AES at RSA conference (David Wagner)
Re: Scaleable Key Permutation Feature (Mok-Kong Shen)
CFP --- CHES 200 (Christof Paar)
Re: NSA opens up to US News ("Henny Youngman")
----------------------------------------------------------------------------
From: "Adrian DuChant" <[EMAIL PROTECTED]>
Subject: Re: need help with a basic C++ algorithm
Date: Thu, 3 Feb 2000 17:04:38 -0800
Cool, Thanks!
The user's shouldn't bee too interested in accessing the data, so I was
hoping to stay away from doing anything too intense, (lack the experience
for the time being). This sounds like it should work just fine though.
Thanks for the help!
Adrian
Trevor Jackson, III <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Adrian DuChant wrote:
>
> > Greetings,
> > I am working on a program which will be using clear text files for basic
> > data storage,
> > I would like to encrypt them and decrypt them at runtime for reading
into
> > the program so as to not allow someone to tamper with the data held
within.
> > This only needs to be basic, nothing really intense.
> > If some one could please give me a hand (or a snippet of code) to make
this
> > algorithm it would be most appreciated.
> > TIA
> > Adrian DuChant.
>
> How proficient are the people who might tamper with the data? There is no
> mechanism that can prevent all tampering.
>
> First, as opposed to obscuring the contents of the data you will need to
verify
> the integrity of the data -- that it has not been tampered with. If this
is
> the sum total of your interest you do no need to encrypt the data, but
simply
> add an integrity check.
>
> Checksums are simple integrity checks. Message Authentication Codes (MAC)
are
> more sophisticated integrity checks.
>
> If you want something really simple just Rot-13 the text (works within the
26
> letter of the alphabet). If you want to be ambitious Rot-47 the text
(works
> within the 94 characters of printable ASCII minus tilde). If the text is
> mostly numeric data Rot-5 it within the decimal digits.
>
>
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: NIST, AES at RSA conference
Date: 6 Feb 2000 12:18:33 -0800
In article <87jcgk$l6q$[EMAIL PROTECTED]>,
Rick Braddam <[EMAIL PROTECTED]> wrote:
> Didn't Terry qualify his statement in terms of known-plaintext and
> defined plaintext?
>
> Is his statement incorrect *with that qualification*?
I didn't think that qualification was much of a qualification.
Typically when we evaluate the strength of a modern cipher, we already
assume that the adversary may be able to mount chosen-text attacks (what
Terry seems to be calling "defined text") -- so if that qualification
introduces a big difference, I'm unable to see what it would be.
(But maybe I'm confused.)
------------------------------
From: Darren New <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Merkle hash tree patent expired
Date: Sun, 06 Feb 2000 20:30:25 GMT
Paul Crowley wrote:
> > > 4,309,569 expired on September 5, 1999. This gives a somewhat clunky
> Where can I find a description of the technique?
www.uspto.gov patent number search.
--
Darren New / Senior Software Architect / IZ, Inc.
San Diego, CA, USA (PST). Cryptokeys on demand.
There is no safety in disarming only the fearful.
------------------------------
From: "Roger Schlafly" <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,misc.int-property,misc.legal.computing
Subject: Re: permission to do crypto research
Date: Sun, 6 Feb 2000 12:41:31 -0800
wtshaw <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> You simply structure the quiery appropriately, like "Let me know if you
> have any objection my studying how such and such program works."
>
> No comment, then you have the freedom to study how everything works,
> including using any tools to assist you in that pursuit.
Sounds reasonable to me, but I am still wondering how this works
in practice. I want to investigate some security aspects of Windows,
and I want to be on the up-and-up, so should I send an email to
[EMAIL PROTECTED]? My guess is that I could spend all day on
the phone to Microsoft, and no one would even know who has
the authority to answer my question.
In the NY court order against DeCSS, the judge seemed to think
that there was some significance to the question of whether some
Norwegian teenager had asked Hollywood for permission to do
his investigation. I doubt that he did. Now I am wondering if
anyone knows how to ask. If there is some accepted procedure
for making the request, I'd like to know it.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re:
Date: Sun, 06 Feb 2000 20:42:36 GMT
In article <
74jn4.364$[EMAIL PROTECTED]>,
"C. Prichard" <[EMAIL PROTECTED]>
wrote:
> That the world is =
> turning to a much heavier reliance on airwaves again in the near future, =
> probably works in favor of the NSA.
>
> -C. Prichard
>
> We don't have enough quality analysis of all this incoming data. Our software can
>search for trigger words, words like "nuclear", but an enemy could transmit decoy
>documents containing mixtures of info that are true, false, or undecideable. Also,
>critical systems are usually not wireless based and may be underground (e.g. a fiber
>optic network). In general, we don't listen in on American citizens unless, for
>instance, it involves the greatest cover-up ever- the empirical and technological
>info obtained regarding extraterrestial biological entities (EBEs).
- da NSA
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: NIST, AES at RSA conference
Date: Sun, 06 Feb 2000 21:10:22 GMT
On 6 Feb 2000 12:18:33 -0800, in
<87kkup$eor$[EMAIL PROTECTED]>, in sci.crypt
[EMAIL PROTECTED] (David Wagner) wrote:
>In article <87jcgk$l6q$[EMAIL PROTECTED]>,
>Rick Braddam <[EMAIL PROTECTED]> wrote:
>> Didn't Terry qualify his statement in terms of known-plaintext and
>> defined plaintext?
>>
>> Is his statement incorrect *with that qualification*?
>
>I didn't think that qualification was much of a qualification.
>Typically when we evaluate the strength of a modern cipher, we already
>assume that the adversary may be able to mount chosen-text attacks (what
>Terry seems to be calling "defined text") -- so if that qualification
>introduces a big difference, I'm unable to see what it would be.
>(But maybe I'm confused.)
My statement was and is correct. But since there are several things
kicking around here, let's just see what you are confused about:
1. If the current best attack on an individual cipher is some sort of
known-plaintext or defined-plaintext (as is quite likely), and that
attack is prevented by multi-ciphering, does that *not* increase the
effective strength of the cipher?
2. If we add a second ciphering action after a first cipher, is it not
clear that -- even in the worst possible case of the opponent knowing
the key to that cipher -- this will increase the effective strength of
the system by the effort involved in deciphering the second cipher?
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: New to cryptology question, rolling XOR
Reply-To: [EMAIL PROTECTED]
Date: Sun, 6 Feb 2000 21:07:33 GMT
Jonas <[EMAIL PROTECTED]> wrote:
: Let say my orginal password is 11011110
: Let's pretend this my text 0100110100001111
[snip XOR table]
: 1100110100001111
: Swap first position to XOR outcome 11011110
: 1000110100001111
: Swap sec position to XOR outcome 10011110
: 1000110100001111
: Swap 3 position to XOR outcome 10011110
: 1001110100001111
: Swap 4 position to XOR outcome 10011110
: 1001110100001111
: Swap 5 position to XOR outcome 10010110
: 1001010100001111
: Swap 6 position to XOR outcome 10010110
: 1001010100001111
: Swap 7 position to XOR outcome 10010110
: 1001011100001111
: Swap 8 position to XOR outcome 10010111
: 1001011100001111
I presume this is a typo.
11011110 EOR
01001101 is
10010011, not
10010111.
: New password string 10010111 applies on bit 9 to 16 creates new password
: that could be used if the text were longer?
: To me it seems like you never can predict the outcome without knowing the
: text or password?
: Isn't it so, and why?
You have an 8-bit key. It doesn't seem hard to apply brute force.
/Even/ if you used a longer key, the securtity would still be poor.
A known partial plaintext which completely overlaps one copy of the key
at any point would immediately reveal the message key. This would be a
disaster for almost any practical cypher.
It's hard to build a cypher around the XOR operator - since it is a
linear operator.
You /need/ to have cyphertext bits to depend on plaintext bits in
a non-linear manner if you are to avoid giving the known-plaintext
attacker a bunch of linear equations to solve, resulting in his finding
the key.
If he has many more message bits than key bits, he will probably wind up
with more linear equations than he has unknowns.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
There's so much to say, but your eyes keep interrupting me.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Combining LFSR's
Date: Sun, 06 Feb 2000 22:19:57 +0100
Ben Curley wrote:
>
> I am attempting to combine the output of two LFSR's to produce a repeatable
> key stream when the start state of LFSR 1 is random. Is this even possible?
It is not entirely clear what you meant by the word 'random' above.
But any combination of pseudo-random number generators without
any 'truly' random elements and outside influenceces is deterministic
and hence the output is necessarily repeatable. (Conversely, if there
are any 'truly' random numbers involved, then there can be by
definition no repetition capabilities.) For diverse combination
schemes of LFSR, see books like those by Menezes et al. and Schneier.
M. K. Shen
=====================
http://home.t-online.de/home/mok-kong.shen
------------------------------
From: "C. Prichard" <[EMAIL PROTECTED]>
Subject: Re: Scaleable Key Permutation Feature
Date: Sun, 06 Feb 2000 21:24:04 GMT
I'm merely announcing that I have conceived feature that adds strength =
to the CipherText algorithm as a natural progression of the algorithm's =
development.
That CipherText works by modifying the primary keys to create a wide =
assortment of permeable cipher combinations makes it unusual among =
patented encryption solutions.
I plan to exploit the approach as far as possible.
When my attorney asked about my other "prior art" regarding my =
application I told him I had some notes. He chuckled a little and then =
explained that prior art is materials that I have "published."
Publicising information in a newsgroup possibly may not qualify as =
"prior art" because it will not turn up in searches with the =
professional field of study. It will definately substantiate that you =
had possesion of said information at the time it was posted though.
Good luck.
-C. Prichard
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: NIST, AES at RSA conference
Date: 6 Feb 2000 14:22:13 -0800
In article <[EMAIL PROTECTED]>, Terry Ritter <[EMAIL PROTECTED]> wrote:
> My statement was and is correct.
I'll repeat my request for a proof, then...
> 1. If the current best attack on an individual cipher is some sort of
> known-plaintext or defined-plaintext (as is quite likely), and that
> attack is prevented by multi-ciphering, does that *not* increase the
> effective strength of the cipher?
Yes, if there are no other attacks that are as good as the one prevented
(and as long as the modification doesn't introduce any new attacks).
But how do you prove that these conditions hold?
> 2. If we add a second ciphering action after a first cipher, is it not
> clear that -- even in the worst possible case of the opponent knowing
> the key to that cipher -- this will increase the effective strength of
> the system by the effort involved in deciphering the second cipher?
No. It is not at all clear that this will increase the strength one whit.
See the previously posted counterexample, using XOR. More generally, any
cipher that forms a group is an obvious counterexample.
Once again, I think this point also needs proof, because in its fully
general form I find it unbelievable, given the apparent counterexamples.
Again, if these things are so clear, it should be straightforward to
encode them in a formal (or at least convincing) proof. But I don't think
they are clear at all. That's why I'm challenging anyone who cares to try
to prove them.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Scaleable Key Permutation Feature
Date: Sun, 06 Feb 2000 23:35:44 +0100
C. Prichard wrote:
>
> That CipherText works by modifying the primary keys to create a wide assortment of
>permeable cipher combinations makes it unusual among patented encryption solutions.
What is the meaning of 'permeable' in the present context?
>From a given key one can generate from it in a number of ways a
longer sequence (though without thereby creating any entropy, of
course). What are the salient features of your method of sequence
generation? Could you please describe that in some clearly
understandable ways?
M. K. Shen
------------------------------
From: Christof Paar <[EMAIL PROTECTED]>
Crossposted-To: comp.arch.fpga,comp.arch.arithmetic
Subject: CFP --- CHES 200
Date: Sun, 6 Feb 2000 17:43:12 -0500
We apolgize for multiple mailings. - Christof
***********************************************************************
Workshop on Cryptographic Hardware and Embedded Systems 2000
(CHES 2000)
http://www.ece.WPI.EDU/Research/crypt/ches
Worcester Polytechnic Institute
Worcester, Massachusetts, USA
August 17 & 18, 2000
Second Call for Papers
General Information
The focus of this workshop is on all aspects of cryptographic
hardware and embedded system design. The workshop will be a forum of
new results from the research community as well as from the industry.
Of special interest are contributions that describe new methods for
efficient hardware implementations and high-speed software for
embedded systems, e.g., smart cards, microprocessors, DSPs, etc. We
hope that the workshop will help to fill the gap between the
cryptography research community and the application areas of
cryptography. Consequently, we encourage submission from academia,
industry, and other organizations. All submitted papers will be
reviewed.
This will be the second CHES workshop. The first workshop, CHES '99,
was held at WPI in August of 1999 and was very well received by
academia and industry. There were 170 participants, more than half of
which were from outside the United States.
The topics of interest include but are not limited to:
* Computer architectures for public-key cryptosystems
* Computer architectures for secret-key cryptosystems
* Reconfigurable computing and applications in cryptography
* Cryptographic processors and co-processors
* Modular and Galois field arithmetic architectures
* Tamper resistance on the chip and board level
* Architectures for smart cards
* Tamper resistance for smart cards
* Efficient algorithms for embedded processors
* Special-purpose hardware for cryptanalysis
* Fast network encryption
* True and pseudo random number generators
Mailing List
If you want to receive emails with subsequent Call for Papers and
registration information, please send a brief mail to
[EMAIL PROTECTED]
Instructions for Authors
Authors are invited to submit original papers. The preferred
submission form is by electronic mail to [EMAIL PROTECTED] Papers
should be formatted in 12pt type and not exceed 12 pages (not
including the title page and the bibliography). The title page should
contain the author's name, address (including email address and an
indication of the corresponding author), an abstract, and a small
list of key words. Please submit the paper in Postscript or PDF. We
recommend that you generate the PS or PDF file using LaTeX, however,
MS Word is also acceptable. All submissions will be refereed.
Only original research contributions will be considered. Submissions
must not substantially duplicate work that any of the authors have
published elsewhere or have submitted in parallel to any other
conferences or workshops that have proceedings.
Workshop Proceedings
The post-proceedings will be published in Springer-Verlag's Lecture
Notes in Computer Science (LNCS) series. Notice that in order to be
included in the proceedings, the authors of an accepted paper must
guarantee to present their contribution at the workshop.
Important Dates
Submission Deadline: April 15th, 2000.
Acceptance Notification: June 15th, 2000.
Final Version due: August 1st, 2000.
Workshop: August 17th & 18th, 2000.
NOTES The CHES dates August 17 & 18 are the Thursday & Friday
preceding CRYPTO 2000 which starts on August 20.
Invited Speakers
Alfred Menezes, University of Waterloo, Canada.
"Elliptic curve cryptography in constrained enviroments"
David Naccache, Gemplus, France.
"How to explain side channel leakage to your kids"
Program Chairs
All correspondence and/or questions should be directed to either of the
Program Chairs:
Cetin Kaya Koc Christof Paar
Dept. of Electrical & Computer Dept. of Electrical & Computer
Engineering Engineering
Oregon State University Worcester Polytechnic Institute
Corvallis, Oregon 97331, USA Worcester, MA 01609, USA
Phone: +1 541 737 4853 Phone: +1 508 831 5061
Fax: +1 541 737 8377 Fax: +1 508 831 5491
Email: [EMAIL PROTECTED] Email: [EMAIL PROTECTED]
Program Committee
Gordon Agnew, University of Waterloo, Canada
Wayne Burleson, University of Massachusetts at Amherst, USA
Kris Gaj, George Mason University, USA
Peter Kornerup, Odense University, Denmark
Arjen Lenstra, Citibank, USA
Jean-Jacques Quisquater, Universite Catholique de Louvain, Belgium
Patrice Roussel, Intel Corporation, USA
Christoph Ruland, University of Siegen, Germany
Joseph Silverman, Brown University and NTRU Cryptosystems, Inc., USA
Colin Walter, Computation Department - UMIST, U.K.
Michael Wiener, Entrust Technologies, Canada
Location
WPI is in Worcester, the second largest city in New England. The city
is 80 km (50 miles) west of Boston and 280 km (175 miles) north-east
of New York City.
Worcester is home to a wealth of cultural treasures, many of which
are just a short distance from WPI. These include the historic
Higgins Armory Museum, which houses one of the world's largest
collections of armor; the EcoTarium (formerly New England Science
Center), one of the only museums in the country dedicated to
environmental education; and the beautifully restored Mechanics Hall,
one of America's finest concert halls. The Worcester Art Museum,
holding one of the nation's finest collections, and the
world-renowned American Antiquarian Society, with the largest
collection of items printed during the nation's colonial period, are
within two blocks of the WPI campus. Worcester is also well known for
its ten colleges, which cooperate through the Colleges of Worcester
Consortium.
Recreation areas within easy driving distance include Boston and Cape
Cod to the east, the White and Green mountains to the north, and the
Berkshires to the west.
August weather in New England is usually very pleasant with average
temperatures of 20 C (70 F).
Workshop Sponsors
This workshop has received generous support from cv cryptovision,
Intel, secunet, and SITI. The organizers express their sincere
thanks.
------------------------------
From: "Henny Youngman" <[EMAIL PROTECTED]>
Subject: Re: NSA opens up to US News
Date: Sun, 6 Feb 2000 15:54:30 -0700
Baloney!!!
Saying the NSA had a computer failure is like saying Phoenix had a
restaurant failure.
No way "ALL" or even a large portion of NSA's computers went south at the
same time.
This is nothing more than a little piece of disinformation planted by our
brothers at the NSA to cover some secret act.
Probably what happened was the US gov't monitored something (that was bound
to be shared by secret agreement with some other nation) and this
information was deemed to sensitive for sharing. They needed some excuse to
avoid sharing it and at the same time provoke support for more funding for
the "poor" NSA. Some clever devil suggested that a Y2K like glitch could
take the heat and provide a boost for funding at the same time.
To think that NSA's computers are tightly coupled enough so that they could
suffer a single point failure is ludicrous. These computer systems are
diverse in time and place of origin as it is possible for computers to be
and they are naturally disposed to be segregated and compartmentalized.
Propaganda!
Dave Hazelwood <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>
>
> http://www.usnews.com/usnews/issue/000214/nsa.htm
>
>
------------------------------
** 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
******************************
