Cryptography-Digest Digest #26, Volume #11 Mon, 31 Jan 00 19:13:01 EST
Contents:
Re: Simple Equivalent keys in Serpent (Tom St Denis)
Re: How to password protect files on distribution CD (Eric Lee Green)
Some applications how the Game of M / General can be used ... play with me ! (Markku
J. Saarelainen)
Re: How to password protect files on distribution CD (Dave Mundt)
Re: Reversibly combining two bytes? (Michael Wojcik)
The Best Books ("Dave Nejdl")
Re: NIST, AES at RSA conference (CLSV)
Re: Intel 810 chipset Random Number Generator (lcs Mixmaster Remailer)
Re: How to Annoy the NSA ("Douglas A. Gwyn")
Re: The Best Books (David A Molnar)
Re: The Best Books (William Stallings)
Re: Pencil & paper cipher question ("r.e.s.")
Re: Intel 810 chipset Random Number Generator (Michael Kagalenko)
----------------------------------------------------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Simple Equivalent keys in Serpent
Date: Mon, 31 Jan 2000 21:04:26 GMT
In article <86cu20$752$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> Hello All,
>
> First off, I don't think this is a weakness in Serpent. It is an
> oddity however.
>
> From looking at the key schedule for Serpent, I believe each 128 and
> 192 bit key has an equivalent 256 bit key.
>
> Quoting from 'Serpent: A Propsal for the Advanced Encryption Standard'
>
> ...
> short keys with less than 256 bits are mapped to full-length keys of
> 256 bits by appending one '1' bit to the MSB end, followed by as many
> '0' bits as required to make up 256 bits.
> ...
>
> Since the key schedule itself does -not- take into account the length
> of the input key and there is no restriction on the selection of 256
> bits keys, it appears that each 128 and 192 bit key has a 256 bit
> equivalent.
>
> By contrast, RC6 and Rijndael both incorporate the length of the input
> key into the key schedule. In either RC6 or Rijndael, a short key
will
> not map to the same rounds keys as a full length key.
>
> A theoritical exploit of the Serpent schedule:
>
> 1. Capture plain/cipher text for a 256 bit key encrpytion
> 2. Capture plain/cipher text for a 128 bit key encryption
> 3. Notice that the cipher text is the same for both
> 4. Brute force the 128 bit and break the 256 bit key.
>
> Not very practical but intesting.
>
> --Matthew
But the thing is not all 256 bit keys have bits 128-254 set to zero, so
these keys are not equivelant.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Eric Lee Green <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.unix,comp.security
Subject: Re: How to password protect files on distribution CD
Date: Mon, 31 Jan 2000 14:46:35 -0700
lordcow77 wrote:
> The standard approach is easily defeated, but a routine whereby
> a valid serial number generates a key stream that decrypts a
> function pointer table on the fly will be significantly more
> involved to crack that changing the result of a cmp.
It doesn't really matter. All you succeed in doing by making it harder is to
make sure that your software is posted on the pirate "hacker" sites by the
person who finally does crack it. In the "cracker" world, the harder the copy
protection is to crack, the more prestige and esteem applies to cracking it.
Frankly, I don't think that, for general purpose software (as vs. games, which
are rather ephemeral in nature), it's worthwhile to spend much more than the
basic amount of time on the license management etc. part of the code. You're
trying to keep honest people honest, you're not trying to foil true thieves
and burglars, who can get into your program no matter what kinds of locks you
put on your doors.
--
Eric Lee Green [EMAIL PROTECTED]
Software Engineer Visit our Web page:
Enhanced Software Technologies, Inc. http://www.estinc.com/
(602) 470-1115 voice (602) 470-1116 fax
------------------------------
From: Markku J. Saarelainen <[EMAIL PROTECTED]>
Crossposted-To: alt.politics.org.cia
Subject: Some applications how the Game of M / General can be used ... play with me !
Date: Mon, 31 Jan 2000 21:43:58 GMT
The Game of M / General can be used in many ways. Here are some
applications how you can use it:
1. Basic Intelligence Professional Mindset Development
2. Shadowing Enemy's Intelligence / Counter-Intelligence Practices
3. Designing and Developing Intelligence Strategies
4. War Gaming (the Game of M is pricipally the War Game)
5. Analyzing, Benchmarking and Evaluating the enemy's Intelligence
Systems
6. Developing you internal intelligence system
7. Auditing and assessing your intelligence system
8. Developing specific counter-intelligence operations and activities
9. Implementing your total competitive intelligence strategy around
your CEO
10. Analyzing and evaluating competitive positions
11. Predicting, signaling and assessing unexpected events affecting a
player's (General's) strategies and anticipating any intelligence
requirements and requirements for preventive actions
12. Developing your internal secret communication system
13. Developing and training your competitive intelligence personal
14. Developing an internal organization for applications of business
intelligence where are corporate employees / members are contributing
to the corporate intelligence cycle.
15. Designing, developing, implementing and training business
intelligence system in an industrial setting (with multi-layer
intelligence cycle approach)
16. Estimating, assessing and analyzing the enemy's counter-
intelligence activities, processes, personnel and other capabilities
and assets
And we can use this Game of M / General anywhere around the world.
Interested in playing the Game of M ...?
Best regards,
Markku
P.S. Cooking is always best with my friends.
P.S. I have communicated 0.01 % of some expertise areas :)
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Dave Mundt)
Crossposted-To: alt.security.pgp,comp.security.unix,comp.security
Subject: Re: How to password protect files on distribution CD
Date: Mon, 31 Jan 2000 21:59:46 GMT
This is a good point.
I think that, really, the only way to deal with these folks is
aggressive prosecution.
Regards
Dave Mundt
Eric Lee Green <[EMAIL PROTECTED]> wrote:
*snip*
>Frankly, I don't think that, for general purpose software (as vs. games, which
>are rather ephemeral in nature), it's worthwhile to spend much more than the
>basic amount of time on the license management etc. part of the code. You're
>trying to keep honest people honest, you're not trying to foil true thieves
>and burglars, who can get into your program no matter what kinds of locks you
>put on your doors.
>
>--
>Eric Lee Green [EMAIL PROTECTED]
>Software Engineer Visit our Web page:
>Enhanced Software Technologies, Inc. http://www.estinc.com/
>(602) 470-1115 voice (602) 470-1116 fax
Remove the "REMOVE_THIS_" from my email address to get to me...
I hate Cullers who gather from newsgroups
Visit my home page at http://www.esper.com/xvart/index.html
------------------------------
From: [EMAIL PROTECTED] (Michael Wojcik)
Subject: Re: Reversibly combining two bytes?
Date: 31 Jan 2000 21:33:41 GMT
Reply-To: [EMAIL PROTECTED]
[My server never received Terry Ritter's post in this thread; I'm
quoting it from Deja.]
Terry Ritter wrote:
[re building a latin square using a random permutation of rotations of
a random permutation]
> Upon cursory reading :-), it looks like it ought to work, and I
> haven't seen it before. There is of course more of a relationship
> than in a true random construction. But it might be interesting to
> investigate Boolean nonlinearity values in the squares produced by
> this method, and compare the distribution to that which occurs in
> random squares.
Now that I've read your web pages on latin squares, I'm also curious
about the nonlinearities (or lack thereof) produced by this method,
or by this method followed random row swapping, which elminates the
rotational relationship among the columns.
I'm looking at your page on Boolean affine functions and nonlinearity
now. With luck, I'll have some time this week to play around with
some square generators based on this method and see how linear they
are.
> Naturally, for any fixed table, if the opponent can traverse and
> identify a substantial portion of the table, or maybe just the part
> most commonly used, not much strength can remain. Ideally we will
> select among a multiple keyed squares, used in several sequential
> levels, for each character ciphered.
It seems to me there's a danger here of consuming too much key material.
We're potentially using the key (or parts of it) to construct multiple
squares, select among squares, and index into squares. My feeling
(possibly wrongheaded) is that the more different parts of the algorithm
consume key material, the greater the danger of leaking bits of the key.
> Question: Can the given method be generalized to construct orthogonal
> Ls's?
Orthogonal might be a difficult target to hit, but generating one
"parent" square using just the two-permutation method, and then
producing some number of "child" squares by shuffling its rows, and
then using the child squares, might be suitable. It might be
possible to salt the shuffling algorithm such that it was unlikely
to end up with two similar children (assuming only a small fraction
of the total possible children are generated).
--
Michael Wojcik [EMAIL PROTECTED]
AAI Development, MERANT (block capitals are a company mandate)
Department of English, Miami University
Don't forget your fighting spirit at each balls you pitch!
-- Tornado Boy Volunteer Staff International
------------------------------
From: "Dave Nejdl" <[EMAIL PROTECTED]>
Subject: The Best Books
Date: Mon, 31 Jan 2000 22:39:15 GMT
I sincerly apoligize because I'm sure this question is well answered in the
faq, but I don't have http access at the moment (very long story). Anyway,
I'm pretty much a beginner to crypto. I'm looking for a book that start's at
a beginner/intermediate level and also covers faily advanced topics (ie.
something I can learn from for a long time). Examples in C are important, as
are the coverage of cryptoanalysis as well as cryptography.
Thank you,
Dave
------------------------------
From: CLSV <[EMAIL PROTECTED]>
Subject: Re: NIST, AES at RSA conference
Date: Mon, 31 Jan 2000 22:58:56 +0000
Bryan Olson wrote:
> CLSV <[EMAIL PROTECTED]> wrote:
> > [EMAIL PROTECTED] wrote:
> > > CLSV <[EMAIL PROTECTED]> wrote:
> > > > A *single* algorithm that breaks *all* key-based ciphers?
> > > > I think/believe that this is awfully close to being
> > > > reducible to the Halting Problem.
> > > By "key based", I mean I'm assuming the usual model in which
> > > the algorithms are known to the attacker and the key is
> > > secret, and by "practical" I mean encryption and decryption
> > > with a given key are reasonably efficient. Clearly if we
> > > allow our solver to take arbitrarily large but finite time,
> > > we could actually construct such a thing, since exhaustive
> > > search halts.
> > But not in polynomial time.
> I was responding to your point about the halting problem,
> which has nothing to do with polynomial time.
If your algorithm does not halt with a solution in polynomial
time I assume it doesn't break an encryption algorithm.
It is probably quite a job to find a reduction between the
super cryptanalysis algorithm and the halting problem
(depending on the definition of breaking an algorithm) but
it seems likely.
Another counter example to the super cryptanalysis algorithm
could start with: assume the algorithm exists, it can be
coded with N states and M symbols now create an optimal
encryption algorithm with 2^(M^2*N^2) states and the same
number of symbols ...
> > Still the problem is too
> > vague to make any specific claims.
>
> In the past I've considered specific models that do consider
> polynomial and exponential time. For an example see:
>
> http://x42.deja.com/getdoc.xp?AN=407897337&CONTEXT=938477175.12452024&hi
I'll look that one up.
> > For example the definition
> > of "breaking a cipher" is very ambiguous. If you consider
> > enumerating all keys until the right one is found than there
> > are no secure ciphers but you say that the existence of
> > such an algorithm is uncertain so you probably don't consider
> > this as breaking a cipher.
> We seek a system that is practical in use and intractable to
> break. There are a variety of ways to model the problem,
> and so far no one has produced a reasonable model in which
> they can prove computational security exists.
So this doesn't mean it can't exist.
But a single algorithm that can break all ciphers
(in less than polynomial time) does definitely not exist.
Regards,
CLSV
------------------------------
Date: 31 Jan 2000 23:20:09 -0000
From: lcs Mixmaster Remailer <[EMAIL PROTECTED]>
Subject: Re: Intel 810 chipset Random Number Generator
Crossposted-To: sci.physics
As a lurker here (and an anonymous one at that) I still must say that this
has been one of the most unproductive debates I have read on sci.crypt.
There is so much left unsaid, so much innuendo, so much allusion to
(unspecified) earlier messages, that communication is impossible.
In what message does Michael Kagalenko define his entropy source?
The closest I can find is
http://www.deja.com/[ST_rn=ps]/getdoc.xp?AN=575544352, where he writes:
> You can produce thermally random
> data by measuring the clock drift against more precise clock (first
> you'd have to find out the crystal frequency, of course). To elaborate
> a bit, if t is precise time, and t' is the time measured by quartz
> oscillator (reclaibrated by using t to avoid systematic drift),
> then
> <t-t'> = 0 (1)
>
> (<> stands for math. expectation), however, that does not
> mean that there is no drift, but that drift in both directions is equiprobable
> (the recalibration I mentioned above consists in making sure that (1)
> holds)
>
> If the drift can be assumed to be brownian random walk,
> the average square drift < (t-t')^2 > grows linearly with time
>
> < (t-t')^2 > = constant * t
We have here a definition of "drift", and from this definition it
does seem plausible that it would move as a random walk. The analog
to particle position in Brownian motion is the total cumulative amount
of drift so far. The total drift is equally likely to move up or down
(with a calibrated clock source), just as a particle undergoing a random
walk is equally likely to move right or left.
Hopefully that sheds light on the analogy with Brownian motion.
However this is not a complete definition of the entropy extraction;
Michael does not describe how he plans to go from this drift to produce
random bits. Presumably though it involves the random change in the
total drift amount. In that case we need a quantitative estimate of
the degree of variability of crystal oscillation periods.
According to http://www.eestech.com/eestech/oscill.html, there are a
number of sources of transient variation in crystal frequency, including
shock and acceleration effects, temperature variation, electromagnetic
interference, and so on. It does not discuss any intrinsic variability
or imprecision in the oscillation, but that is presumably of a smaller
magnitude than, say, accelerating the crystal by 2 g's. (Otherwise the
effects described on this web page would not be observable, being swamped
by the intrinsic variability of crystal oscillation period.)
Most of the effects listed there are of the order of one in 10^9.
The thermal impact is potentially larger, but temperatures are unlikely to
vary by more than a fraction of a degree over a relatively short period,
bringing this effect down to roughly this magnitude as well.
If we take this as an upper limit on the natural variability of the
crystal frequency over short time periods, then a 100 MHz oscillator
would count almost exactly the same number of clock periods every second.
Only about one second in ten would there be a difference of even one cycle
from the previous measurement. If we adjust the reference (perfect)
clock to match our crystal, then clock drift will be only on the order
of one tick per ten seconds.
If we had a higher frequency clock this would be faster; a 1 GHz crystal
might have a clock drift of one tick per second.
Based on this Michael's critics appear to be correct, that quartz
crystals are so stable that clock drift would occur at a very slow rate.
This is an unsuitable source of random numbers, unless they are needed
very rarely.
There, was that so hard?
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: How to Annoy the NSA
Date: Mon, 31 Jan 2000 23:25:07 GMT
[EMAIL PROTECTED] wrote:
> ... Some or
> many of the NSA's codes have depended on the
> intractability of NP- Complete problems
> which could become vulnerable to this type of
> computer.
I doubt that you have a clue about "NSA's codes".
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: The Best Books
Date: 31 Jan 2000 23:15:58 GMT
Hi,
You may be happy with _Applied Cryptography : Protocols, Algorithms,
and Source Code in C_. It gives great intuition as to which algorithms
do what and how. It's also written in an engaging, informal style
(unfortunately, this means no proofs -- the "why" sometimes lacks).
When you get http access back again, the _Handbook of Applied
Cryptography_ is available for free from the authors' web sites.
You will want it before trying to implement any production
cryptosystem. In particular, it covers questions like
"so, how exactly do I set parameters for these cryptosystems?
quickly?"
and "my C compiler doesn't support bignums. How do I build my own?"
in much more detail than _Applied Crypto_ does.
For cryptanalysis, both books just summarise best known results; you're
not going to learn how to be a cryptanalyst from reading them. In
addition, _Applied Crypto_ was written before the AES candidates were
announced, so it doesn't cover them (for that you need to go to the
Block Cipher Lounge web page).
I'm not sure which book would have a good overview of public-key
cryptanalysis...is there one? Neal Koblitz _A Course in Number
Theory and Cryptography_ covers various factoring algorithms up
to the Number Field Sieve, but it doesn't really cover some of
the ways in which public key schemes have been found to break.
Anyone know of a good reference / repository for public key
cryptanalysis results?
Thanks,
-David
Dave Nejdl <[EMAIL PROTECTED]> wrote:
> I sincerly apoligize because I'm sure this question is well answered in the
> faq, but I don't have http access at the moment (very long story). Anyway,
> I'm pretty much a beginner to crypto. I'm looking for a book that start's at
> a beginner/intermediate level and also covers faily advanced topics (ie.
> something I can learn from for a long time). Examples in C are important, as
> are the coverage of cryptoanalysis as well as cryptography.
> Thank you,
> Dave
------------------------------
From: [EMAIL PROTECTED] (William Stallings)
Subject: Re: The Best Books
Date: Mon, 31 Jan 2000 18:47:17 -0500
In article <naol4.83$[EMAIL PROTECTED]>, "Dave
Nejdl" <[EMAIL PROTECTED]> wrote:
> I sincerly apoligize because I'm sure this question is well answered in the
> faq, but I don't have http access at the moment (very long story). Anyway,
> I'm pretty much a beginner to crypto. I'm looking for a book that start's at
> a beginner/intermediate level and also covers faily advanced topics (ie.
> something I can learn from for a long time). Examples in C are important, as
> are the coverage of cryptoanalysis as well as cryptography.
>
You might consider my book,
Cryptography and Network Security: Principles and Practice, 2nd Edition
(1999, ISBN 0-13-869017-0)
Winner of the 1999 Texty Award for the best Computer Science and
Engineering textbook, awarded by the Text and Academic Authors
Association, Inc.
Bill
| | Descriptions, errata sheets and discount order info |
| | for my current books and info on forthcoming books: |
| Bill Stallings | WilliamStallings.com |
| [EMAIL PROTECTED] | |
| | Visit Computer Science Student Support site: |
| | WilliamStallings.com/StudentSupport.html |
------------------------------
From: "r.e.s." <[EMAIL PROTECTED]>
Subject: Re: Pencil & paper cipher question
Date: Mon, 31 Jan 2000 15:56:13 -0800
"Tony T. Warnock" <[EMAIL PROTECTED]> wrote ...
: What would be wrong with extending the cypher that Terry Ritter
: described using a double Playfair. First do a simple transposition: for
: example, write the plaintext in order: p1, pn, p2, pn-1,...etc, that is,
: first, last, second, penultimate, third, antepenultimate, fourth, etc.
: Then do a playfair on the first key. Append nulls at the beginning and
: end, the Playfair again on a second key. Append nulls and Playfair on
: the third key. A simple transpositon could be done between Playfairs.
I must have missed that posting by Terry Ritter, but I did see
one by Jim Gillogly (last week?) in reply to someone asking about
the best order in which to mix transposition and Playfair. As I
recall, he thought that TTP would make a challenging cipher for
pencil & paper, with T=double-transposition and P=double-Playfair.
If I understand your closing suggestion, the cipher you have in
mind would be tPtPtP, where t is some non-keyed and very simple
transposition method, and P=double-Playfair.
Both of the above descriptions completely omit *how* keying is to
done (e.g. processing some sort of passphrase, etc.). A very
great deal of the VIC cipher is devoted to nothing but this part:
setting up keys for (1) a simple straddling checkerboard, and
(2) a double-transposition. All of the LSFR stuff is an attempt
to generate these keys from a passphrase in a secure manner.
So if we are to make a comparison with the above ciphers, the
comparable part of VIC could be designated as CT, where C is
converting the plaintext letters into digits using a stradding
checkerboard, and T is double-transposition.
:
: The idea is to be simple for pencil and paper.
:
Imo, VIC's algorithm (CT) is simpler than either TTP or tPtPtP.
To implement any of these with a secure use of passphrases will
require significant care and effort, and VIC's method for doing
that seems to be a worthy case-study.
--
r.e.s.
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Michael Kagalenko)
Crossposted-To: sci.physics
Subject: Re: Intel 810 chipset Random Number Generator
Date: 31 Jan 2000 23:52:55 GMT
Reply-To: [EMAIL PROTECTED]
John A. Sidles ([EMAIL PROTECTED]) wrote
]>>Noise does not change crystal oscillation frequency, even
]>>instantaneously. The crystal continues to physically flex and vibrate
]>>at exactly the same frequency.
]
]Dear sci.crypt folks
]
]The question of whether the noise output from a thermally
]excited oscillator is really "random" is quite fascinating.
]We observe this noise all the time in our force microscope
]experiments, and we spend a lot of time wondering whether
]it is really random.
]
]We will consider any thermally excited oscillator -- like a
]piezoelectric crystal, or a force microscope cantilever, or an LC
]circuit. With all feedback circuits turned off, it is easy to
]measure the damping time $\tau = \omega_0/Q$ of the oscillator.
]Here:
]
] $\tau$ = damping time of the oscillator
] $\omega_0$ = resonant frequency
] $Q$ = quality (dimensionless)
]
]Typical values of Q can be anywhere from 300 (for LC circuits)
]to 1000,000 (for cryogenic crystals).
]
]To make a clock, we install an active feedback circuit (typically
]a phase-lock loop "PLL") and operate the device as a free-running
]oscillator. The device is now characterized by two more
]parameters:
]
] $E$ = energy of the oscillator
] $\tau_{PLL}$ = time constant of the PLL
]
]See Horowitz and Hill "The Art of Electronics" for a very good
]discussion of PLL circuits.
]
]We will design our PLL (and it is not hard to realize in practice)
]such that
]
] $\tau_{PLL} >> \tau$ (slow PLL time constant)
]
]We will also assume that the PLL adds negligible noise to the
]circuit; this also is possible to realize in practice, but can
]be challenging.
]
]Now, in the absence of thermal noise, the frequency of the
]excited oscillator would be perfectly constant. But of course,
]thermal noise always *is* present, and it is not too hard to show
]that it is indistinguishable from an equivalent "jitter" in
]$\omega_0$ whose spectral density $S_{\omega_0}$ is
]
] S_{\omega_0} = ( \omega_0/Q ) (k_B T / E)
]
]where $k_B$ is Boltzman's constant and $T$ is the ambient
]temperature. Note that this formula applies to all kinds of
]free-running oscillators. It represents the thermodynamic
]limit of their accuracy.
I agree with that so far, however, it is not clear what you mean
by the equivalent "jitter" which you distinguish from the
"thermal noise." From the formula that you give for that
jitter it looks like you are simply using two different
names for the same phenomenon.
]We see that accurate clocks, whatever their type, require (1) low
]temperature $T$, (2) high quality $Q$, and (3) large excitation
]energy $E$.
(What I said several times over)
]Any circuit that
]
] (1) monitors the free-running oscillator, and
] (2) computes the instantaneous frequency $\omega$, and
] (3) low-pass filters the measurement with some time
] constant $RC << \tau_{PLL}$
]
]will supply random noise. This noise will be of the so-called
]Ornstein-Uhlenbeck type, i.e., Gaussian noise with an
]exponential decorrelation time RC.
]
]Of course, the above discussion is quite idealized -- it is much
]less clear that there is any easy way to extract cryptologically
]impeccable random bits from, e.g., the clock circuit of an INTEL cpu.
The noise in $\omega$ would result in accumulated error
in the phase, like the random forces on Brownian particle
result in its drifting away from its original position.
]On the other hand, there is at least the possibility that
]thermal noise observed by a continuous quantum measurement
]process could be proved to be random in the strict
]information-theoretic sense of Chaitin and Kolmogorov --
]see http://xxx.lanl.gov/abs/quant-ph/9612001.
------------------------------
** 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
******************************
