Cryptography-Digest Digest #525, Volume #9 Mon, 10 May 99 22:13:03 EDT
Contents:
TOMSTDENIS AND SCOTT ARE THE SAME PERSON-- ([EMAIL PROTECTED])
Re: Thought question: why do public ciphers use only simple ops like (Bryan Olson)
Re: HASH and XOR (kurt wismer)
Re: Thought question: why do public ciphers use only simple ops like (Bryan Olson)
Re: TOMSTDENIS AND SCOTT ARE THE SAME PERSON-- ([EMAIL PROTECTED])
Re: Factoring breakthrough? (ca314159)
Lemming and Lemur: New Block and Stream Cipher (Anonymous)
Re: TOMSTDENIS AND SCOTT ARE THE SAME PERSON-- (Jim Gillogly)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: TOMSTDENIS AND SCOTT ARE THE SAME PERSON--
Date: Mon, 10 May 1999 23:12:08 GMT
TOMSTDENIS AND SCOTT ARE THE SAME PERSON: clueless
TOMSTDENIS AND SCOTT ARE THE SAME PERSON: clueless
TOMSTDENIS AND SCOTT ARE THE SAME PERSON: clueless
TOMSTDENIS AND SCOTT ARE THE SAME PERSON: clueless
TOMSTDENIS AND SCOTT ARE THE SAME PERSON: clueless
TOMSTDENIS AND SCOTT ARE THE SAME PERSON: clueless
--
Revocable Limited License Agreement with Mandatory Perpetually Binding
Disclaimer of Responsibility ("RLLAMPBDR") Version 3.2:
1. DISCLAIMER OF RESPONSIBILITY
All responsibility is disclaimed by the creator or originator
("SENDER") of this email communication ("MESSAGE") for any conclusions
that the designated recipient/s ("RECIPIENT/S") may assert from the
MESSAGE, whether stated, implied, or otherwise. The materials contained
in the MESSAGE, including headers, quoted passages, forwards, signature
files, RLLAMPBDR, and attachments ("CONTENT"), have not been verified
by the SENDER for validity or accuracy and should not be interpreted as
a statement or implication of the truth.
2. CONTENTS OF MESSAGE AND VERIFICATION OF SENDER
The CONTENTs of the MESSAGE do not necessarily originate from
the apparent SENDER unless: I) the headers nonambigiously show the
purported SENDER as the true SENDER of the message defined as the
internal consistency of the "From:", "To:", "Received:", "Message-ID:",
and any other pertinent fields, II) no tokens generally accepted as
quote indicators, here defined as ">", "|", "-", "<", "+","=", "!",
"~", "@", "`", or ":", appear at the beginning of a line, III) a
current copy of the RLLAMPBDR appears in full, and IV) a valid digital
signature
exists, defined as a congruence between the pre and post-images of the
CONTENT vector generated by a non-invertable, collision-resistant
transformation permutated over the field Zn or Gp where p is a large
prime of multiplicative order not less than 2^1023 or n is the product
of two large primes each exceeding 2^511, originating from the SENDER,
collectively designated as ("VERIFIABILITY CONSTRAINTS").
3. LICENSING AND STORAGE CONDITIONS FOR RECIPIENTS
The RECIPIENTS are defined as the entity or entities listed in
the "To:" section of the MESSAGE's header, not inclusive of the "Cc:"
or "Bcc:" sections, to which a limited, nontransferable, nonexclusive
license ("LICENSE") for viewing on a single, nonshared, private
("SECURE") display device is provisionally granted. 1 (ONE) archival
copy of this MESSAGE is permitted on a storage device, mechanical or
electronic, subject to the constraint that it can justifiably be
claimed, subject to independent audit at any time, that access to the
aforementioned device can be restricted to the RECIPIENT ("RESTRICTED
ACCESS"). Moreover, SECURE viewing or storage must satisfy these
requirements: I) the SECURE viewing or archival location cannot be
publicly accessible, II) the CONTENTS of the MESSAGE, in any form, may
never exist in a location that has the potential for occupancy by non-
LICENSED individuals, III) the SECURE viewing area is sufficiently
isolated such it is not possible for a non-LICENSED individual to
observe or monitor the display at any time, and IV) the SECURE storage
object must be non-removable from its intended location without the use
of at least 7 (SEVEN) of the following items: I) a hammer, II) a
screwdriver, III) a blowtorch, IV) a wrench, V) a drill, VI) a saw,
VII) a key, VIII) any mechanical force-increasing device, IX) a device
that projects any form of thermal energy, X) a strong acid or base, XI)
any incendiary device, or XII) any form of explosive.
4. REDISTRIBUTION LIMITATIONS
This MESSAGE may not be forwarded, replied to, made available
to or otherwise communicated ("REDISTRIBUTED") to parties not
possessing a valid LICENSE for viewing this specific MESSAGE. The
MESSAGE may be REDISTRIBUTED to LICENSED RECIPIENTS provided: I) no
modifications occur such that the intent or meaning of the original
MESSAGE would be altered, II) the RLLAMPBDR is reproduced in full, and
III) the SENDER is notified of such REDISTRIBUTION in an expedient
manner within a period not to exceed 72 (SEVENTY TWO) hours. All
liability is disavowed by the SENDER for the ramifications, intentional
or unintentional, of unauthorized REDISTRIBUTION. RECIPIENT/S must
reaffirm their consent to the updated RLLAMPBDR before REDISTRIBUTION
is authorized. No charge for REDISTRIBUTION may be imposed on secondary
RECIPIENTS beyond a nominal handling fee not to exceed 3 (THREE) cents
per 1000 (ONE THOUSAND) bytes transferred. Additionally, the RECIPIENT
must surrender the MESSAGE and all of its associated CONTENTS,
including this RLLAMPBDR, upon request by the SENDER and must also
provide proof that the RECIPIENT is no longer in possession of the
MESSAGE in any form that enables its eventual recovery ("COMPLETE
DESTRUCTION"). No derivative works may be created from the CONTENTS of
this MESSAGE.
5. CHANGES IN AGREEMENT BETWEEN SENDER AND LICENSED RECIPIENT
The RLLAMPBDR may change without notice, with no obligation by
the SENDER to inform prior RECIPIENTS of such a change. Upon revision
of the RLLAMPBDR, all previous MESSAGES covered under previous versions
of the RLLAMPBDR become subject to the conditions of the modified
RLLAMPBDR with a grace period of 24 (TWENTY-FOUR) hours before
compliance becomes mandatory. This LICENSE must not be construed to
limit the restrictions imposed on the RECIPIENT by the RLLAMPBDR, nor
should it be interpreted as a full statement of the restrictions
imposed on said RECIPIENTS.
6. ADDITIONAL INFORMATION
In the event of an inconsistency between this document and any
other disclaimer, the RLLAMPBDR will take precedence in all cases. In
the event of an ambiguity or inconsistency within the RLLAMPBDR, the
RECIPIENT is required to I) notify the SENDER within 2 (TWO) days of
this discovery, II) immediately cease any actions that would be
affected by such an ambiguity within the RLLAMPBDR, III) maintain
strict non-disclosure standards regarding such a discovery, and IV)
receive written or electronic communication from the SENDER, satisfying
the VERIFIABILITY CONSTRAINTS, before resuming any activities involving
the rights granted and obligations imposed by the RLLAMPBDR. If
multiple copies of the RLLAMPBDR are present in a MESSAGE, the latest
one shall take precedence. For the purposes of this document, all
communications regarding the RLLAMPBDR, including potential errors,
clarifications, or request of additional granted rights, shall be
directed to the <[EMAIL PROTECTED]> ("ADMINISTRATIVE CONTACT").
7. TERMS OF REVOCATION OF LICENSE AND LIMITATIONS TO IMPLIED RIGHTS
The LICENSE is revoked if the RECIPIENT does not agree to the
RLLAMPBDR in its entirety. The LICENSE is also revoked if the RECIPIENT
signals an intention to no longer abide by the terms of the RLLAMPBDR.
This LICENSE can also be revoked when clear and convincing evidence
exists that one or more obligations outlined in the RLLAMPBDR has been
breached. Either party may revoke the RECIPIENT's LICENSE at any time.
Upon revocation of the LICENSE, RECIPIENT must ensure the COMPLETE
DESTRUCTION of this MESSAGE within 8 (EIGHT) hours of termination of
LICENSE. Furthermore, the RECIPIENT is not released from the
confidentiality requirements or any other responsibilities imposed by
of the RLLAMPBDR and must abide by the restrictions imposed on all
other RECIPIENTS, both LICENSED and non-LICENSED in perpetuity. The
conditions under which the MESSAGE is sent to the former RECIPIENT
continue to apply in perpetuity unless released by the SENDER in a
message that satisfies the VERIFIABILITY CONSTRAINTS. No rights are
granted for use of this MESSAGE or its CONTENTS beyond the terms of the
RLLAMPBDR without specific permission from the SENDER satisfying the
VERIFIABILITY CONSTRAINTS. This LICENSE grant is only valid for this
specific MESSAGE and is nontransferable.
A. TECHNICAL CLARIFICATION ANNEX A
The following public key shall be used for the purposes of the
VERIFIABILITY CONSTRAINTS. This public key are available upon from
<[EMAIL PROTECTED]> or from http://www.nowhere.com. In the event of
any discrepancy between the keys stored at these locations, the
ADMINISTRATIVE CONTACT must be notified within 1 (ONE) day.
//End of RLLAMPBDR Version 3.2
--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: Thought question: why do public ciphers use only simple ops like
Date: Mon, 10 May 1999 13:52:20 -0700
John Savard wrote:
>
> [EMAIL PROTECTED] wrote, in part:
>
> >I do believe that amateurs can design strong symmetric ciphers,
> >provided they know some fundamentals, work carefully, and build
> >in large safety factors.
>
> This makes it possible that one _could_ get around the basic objection
> to his proposed scheme.
Let me see if I follow. If we assume each cipher in the candidate
pool is secure, then there's no security problem with Ritter's
suggestion. There's also no reason for it.
[...]
> >And not in the way people seem to think. Ciphers by themselves
> >offer poor authentication, and the authentication of the selection
> >channel is far more important than its privacy. If I can find a
> >way to forge, I can get you to use _my_ choice of your ciphers.
>
> I don't believe the system is to be designed so as to allow either
> user to control the other user's choice of ciphers: agreement is
> required from both. Once the pool of ciphers is established, the
> sender would be the one making the random choice, just as the sender
> generates the session key.
He has to choose one that the receiver implements, and I'm not
sure how we'd establish what's in the common pool without the
authenticated channel.
> Given a private selection channel, and the use each time of three
> ciphers taken from a pool of 1000, for example, one has:
>
> - added 30 bits to the difficulty of a brute-force search,
>
> - reduced the probability that the three weakest ciphers will be those
> chosen to an acceptable level.
The set of all ciphers is closed under composition. The composition
of three ciphers is itself a cipher - one with the strange structure
and a dumb key schedule. Multiple encryption is one way someone
might choose to build in a large safety factor.
--Bryan
------------------------------
From: kurt wismer <[EMAIL PROTECTED]>
Subject: Re: HASH and XOR
Date: Tue, 11 May 1999 02:47:16 GMT
Neonnate2 wrote:
>
> Hello, I am a newbie to strong cryptography. Sure, I've done a few simple
> one-key XOR loops in my silly assembler programs. You know the drill...
or maybe they don't - i wouldn't want to guess at how many of the
participants here are members of the virus writing/distributing
community... my gut tells me the number is relatively small, however...
> Anyhow,
> I've since become intrested in getting started in a strong cryptographical
> background. Now, I read, and heard from my friends that are further in crypto
> that a fairly strong (not crack-proof, but still strong enough) alogorythm
> could be formed by a simple XOR loop, and a strong HASH routine. Well, what I'm
> wanting to ask, is does anyone have an example of this in pure Assembler?
hmmmm... now why, i wonder, would you be wanting an example? it wouldn't
really explain anything about cryptography or why one method is stronger
than another, it would seem to be best suited to use as a template to
cut and paste into some other code...
standard advice for anyone wishing to become more familiar with crypto
is, i think, to read the relevant literature... to which i'd direct you
towards schneier's "applied cryptography" - 14.11 of the second edition
explains this use of hash functions quite nicely, i find, though it may
be necessary to read other sections aswell to get the full value... but
hey, if you're interested in learning more about crypto then reading a
book about it shouldn't be unreasonable...
--
"close your eyes and bow your head
i need a little sympathy
cause fear is strong and love's for
everyone who isn't me"
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: Thought question: why do public ciphers use only simple ops like
Date: Mon, 10 May 1999 14:04:13 -0700
[EMAIL PROTECTED] (Terry Ritter) wrote:
> [EMAIL PROTECTED] wrote:
>
> >[...]
> >To me, a strong cipher is one for which there is no tractable
> >break. If a devastating attack exists, the difficulty of finding
> >it does not, in my view, have anything to do with the strength of
> >the cipher.
>
> But this "absolute strength" idea is something we cannot know.
[...]
>
> On the other hand, there is something to the idea of a relative or
> "contextual strength." That is, any cipher has the ability to confuse
> an opponent of x capabilities (x being some combination of background,
> time and resources), but not an opponent whose capabilities are
> greater.
Too bad the adversary knows x and we don't.
> >[...]
> >I don't think hiding a weak cipher among
> >a thousand strong ones buys much.
>
> It buys the consequence that 999 messages of 1000 will not be exposed.
That's separate issue, already dealt with. The issue under
discussion with John Savard is how hard it is do distinguish
ciphers we can break.
--Bryan
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: TOMSTDENIS AND SCOTT ARE THE SAME PERSON--
Date: Tue, 11 May 1999 01:13:49 GMT
Ok let's see I am scott. Interesting.
Here is a lesson, call me at 613-836-3160, I will talk to you a bit.
I am nothing like Scott (no offense), we work on different areas and
have different ideas.
Please tell me why you would think this? Maybe we can resolve this in
a civil manner.
Tom St Denis
--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---
------------------------------
From: ca314159 <[EMAIL PROTECTED]>
Subject: Re: Factoring breakthrough?
Date: Tue, 11 May 1999 01:32:33 GMT
Mike McCarty wrote:
>
> In article <7h2i7i$ag7$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
> )In article <[EMAIL PROTECTED]>,
> ) [EMAIL PROTECTED] (wtshaw) wrote:
> )> In article <7h19ac$aaj$[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>
> )> Precison of an analog device depends largely on the observer, which might
> )> be finer than the abilities of a digital instrument to quantify, or not.
> )> Your first line is not necessarily true; it all depends on the
> )> circumstances.
> )
> ) I suspect that one of these, is always traded at the expense of
> ) the other in the finest level of detail, just as waves are traded
> ) for particles and vice versa in quantum mechanics leading to
> ) the idea of the generic wave-particle or quanta which tries to
> ) manage the dualism wholistically (not necessarily holistically
> ) since quantum field theory is still in its infancy).
>
> Precision relates to repeatability of a result. Accuracy relates to the
> "correctness" of the result.
>
> In probabilistic terms, precision is something like the reciprocal of
> dispersion measures, whereas accuracy relates to the location measures.
> Any measurement has a variance. If the variance is low, the precision is
> high. If the expectation of the measurement is very closely equal to the
> actual value, then the accuracy is high.
>
> I don't see any connection. For some distributions, the mean and
> variance are independent.
In signal processing certain meaurements are complementary.
(See for instance Reid and Passin's book Signal Processing in C
which also shows how signal processing is related to the
quantum physical Heisenberg uncertainty) A simple case in signal
processing is that frequency and the time of the measurement of
that frequency are given by the uncertainty relation
\delta f \delta t >=1/2
which is metaphorically literal to Heisenberg's
\delta E \delta t >= h /2
where E=hf.
So any increase in the precision of the measure of frequency
reduces the corresponding precision in the measure of the
time of measurement of that frequency (how do you measure
where a large object is, you have to arbitrarily pick a single point
out of many on that object as "the point representing where the object is")
Same thing for particles and waves. These are complementary "concepts"
in which the more you "resolve" one, the less you "resolve" the other.
"resolve" used here meaning that you resolve the concept and not its parts,
so a wave that is infinitely resolved is a pure wave without any
particulate nature. But if you "dissect" a wave, you find particles.
A microscope lense trades for the precision of parts, the accuracy of the whole.
Or a zoo trades for the precision of observing a lion, for the accuracy
of knowing what the lion is like in the wild.
> I'm often amused by electronics types who think that they should use
> V/F converters for good A/D conversion because they can, in principle,
> have as many bits of precision as they like, simply by making the
> counter which measures the frequency have more bits. I mean, I've seen
> in literature stated that one can get 13 bits of precision out of a
> certain V/F (synchronous, crystal driven) by just using a long enough
> counter. They didn't mention that when one computes the temperature
> drift, that could be achieved only by
>
> characterizing the parts on a piece by piece basis
>
> maintaining temperature within a half a degree C or so
>
> Anyway, this is probably getting pretty far off topic.
Sort of. That's the problem really. We draw lines saying
cryptography is this and related to nothing more. Like the
caged lion it is nothing more than the animal we see in the
cage. But at the edge of every cage, category, classification,
there is uncertainty as to what is and what isn't inside those
mental containers.
We humans are raised in binary to say this is a cup and there
is no doubt I am holding a cup. But at the most fundamental
level of information the cup is defined as much by what it is
as by what it is not. You really have to know completely what
the entire universe is, to define that cup.
Cryptography is the reverse of this. It tries to hide the cup
by forcing you to define the rest of the universe before you
can have the cup.
--
http://www.bestweb.net/~ca314159/
------------------------------
Date: Tue, 11 May 1999 03:56:32 +0200 (CEST)
From: Anonymous <[EMAIL PROTECTED]>
Subject: Lemming and Lemur: New Block and Stream Cipher
Lemming is a new block cipher and Lemur is a new stream cipher.
They are designed to be as simple as possible while still being
secure. The two algorithms are very similar.
Lemming encrypts a 128-bit block, and Lemur outputs a stream of
bytes. Both use a 4 KB key, and no other tables or S-boxes.
They could both fit on a smart card with 4 KB flash and no RAM.
They are also fast: Lemming is 19 cycles/byte on a PII without
MMX, and should be much faster on more powerful architectures.
Lemur does half as many calculations per byte as Lemming, though
it isn't necessarily twice as fast. The algorithms are:
VARIABLES:
block = 128-bit integer
block[0] = first byte of block
plaintext = array of plaintextLength bytes to encrypt
key[0...255] = array of 256 integers, 128 bits each
rotate(block) = 8-bit rotation so block[0] moves to block[1]
TO LEMMING ENCRYPT A BLOCK:
for (i=0; i<32; i++)
block = rotate(block ^ key[block[0]]);
TO LEMUR ENCRYPT PLAINTEXT:
block = random 128-bit salt
output (block)
for (i=0; i<32; i++)
block = rotate(block ^ key[block[0]]);
for (i=0; i<plaintextLength; i++)
{
output (block[8] ^ plaintext[i]);
block = rotate(block ^ key[block[0]]);
}
TO GENERATE A NEW KEY:
perm[0..255] = random permutation of the bytes 0 to 255
key[i][0] = i XOR perm[i]
key[i][1..15] = 15 random bytes
Obviously, "key" could also be generated from a shorter key or a
passphrase, but for simplicity it is assumed to be generated by
a TRNG.
Any comments?
LCB
[EMAIL PROTECTED]
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: TOMSTDENIS AND SCOTT ARE THE SAME PERSON--
Date: Mon, 10 May 1999 18:54:40 -0700
[EMAIL PROTECTED] wrote:
> I am nothing like Scott (no offense), we work on different areas and
> have different ideas.
Aha! Proof positive that you are not Scott. You used a comma
splice in this sentence. Although that is a grammatical error
(a first-order Scott identification mechanism), he uses commas
only in his C programming -- never in his English-like text.
If anybody can turn up a Scott article in the archives that
contains a comma in text he wrote (rather than quoted), I'll
(virtually) eat my words.
Must remember to include this identification mechanism in my
stylometric analysis program.
--
Jim Gillogly
Sterday, 20 Thrimidge S.R. 1999, 01:48
12.19.6.3.5, 8 Chicchan 13 Uo, Second Lord of Night
------------------------------
** 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
******************************
