Cryptography-Digest Digest #303, Volume #9 Tue, 30 Mar 99 14:13:04 EST
Contents:
fast enough (sequel) ([EMAIL PROTECTED])
Re: True Randomness & The Law Of Large Numbers ("Tony T. Warnock")
Re: Wanted: free small DOS Encryption program ([EMAIL PROTECTED])
Re: newbie question (William Hugh Murray)
Re: Live from the Second AES Conference (David Wagner)
Re: Live from the Second AES Conference (Jim Gillogly)
Re: strong brain-embedded decryption algorithm ("Alex")
Re: ---- Two very easy secret key Cryptosystems (Fiji)
Re: True Randomness & The Law Of Large Numbers (R. Knauer)
Re: Wanted: free small DOS Encryption program - rc4.exe (0/1) ("Arthur N. Klassen")
Re: Random Walk (R. Knauer)
Re: Encryption and the Linux password files (John Savard)
Re: Wanted: free small DOS Encryption program (Patrick Juola)
Re: Live from the Second AES Conference (John Savard)
Re: Testing Algorithms [moving off-topic] (Doggmatic)
Re: Does anyone know how to solve vigenere and tranposition cipher? (John Savard)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: fast enough (sequel)
Date: Tue, 30 Mar 1999 12:18:40 GMT
Why on earth should the algorithm work at 50mb/s on a PC? Unless you have
specialized hardward or something...
I realize the algorithm should be efficient and fast, but on a PC I would
think
>= 2MB a sec is ok. Probably around 8MB a sec would be best.
In hardware, well if you have a cipher core (cpu) then I can't see this as a
problem.
Tom
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: "Tony T. Warnock" <[EMAIL PROTECTED]>
Subject: Re: True Randomness & The Law Of Large Numbers
Date: Tue, 30 Mar 1999 09:07:54 -0700
Reply-To: [EMAIL PROTECTED]
"R. Knauer" wrote:
> Calculate the frequency of particles that are within +- 5% of the mean
> in n steps for the uniform Bernoulli process. The mean for the random
> walk is zero, namely the origin. And the extremes are at +- n.
>
> Compare that frequency with that for all the rest of the sequences.
> For reasonably large n, the frequency of sequences that are within +-
> 5% of the mean (the origin) is small. Most of the sequences are
> outside +- 5%. The reason is that the Gaussian profile has flattened
> out considerably.
Actually this is false. For a Bernoulli process with p=.5 the standard deviation is
Sqrt(N)/2. The normalized Z-score for your bounds of +-5% is then .05N/Sqrt(N)/2 or
.10*Sqrt(N). This means that the Z score is growing with increasing N. A sample
computation shows that for N=100 that 72% of the samples lie within +-5% of the
mean.
Tony
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: comp.security.misc
Subject: Re: Wanted: free small DOS Encryption program
Date: Tue, 30 Mar 1999 14:49:48 GMT
In article <7dpqev$ovj$[EMAIL PROTECTED]>,
Milton Pomeroy <[EMAIL PROTECTED]> wrote:
> Wanted - a free DOS-based encryption program which is small, fast,
> strong and friendly
>
> Explanation
>
> I want recommendations of encryption software to store small amounts of
> sensitive information (up to 30kbytes) for my own use - i.e. I encrypt it,
> and I decrypt it. Since I plan to carry the encrypted datafile and
> encryption software on floppy disk and use it on various PCs (some of which
> may not be owned by me), I plan to use it from DOS (don't want to load it on
> PC, don't want any temporary decrypted data left on the PC's hard-disk). The
> PCs will be running DOS, Win95/8, or WinNT. Typically, I'd run it from the
> floppy in a DOS-Window.
>
> The mandatory requirements therefore are:
>
> (1) runs from DOS (and DOS-prompt in a DOS-Window)
>
> (2) freeware/public domain
>
> (3) be accessible to someone (like me in Australia) who is outside USA
> (no export restrictions)
>
> (4) works in 450kBytes or less of RAM
>
> (5) already compiled i.e. an EXE or COM version is available
> (I don't want the uncertainty of my doing a poor compilation
> resulting in a poor security implementation)
>
> (6) EXE or COM file must be small - less than say 80kbytes
> (if it's large, like PGP for DOS at around 400kbytes, it takes
> over 10sec to load from floppy-drive)
>
> (7) fast execution - less than say 5 seconds to load from floppy
> and complete encryption/decryption of up to 30kBytes of data
> on a 486-66
>
> (8) can run from a floppy with any temporary files being stored on the
> floppy
>
> (9) strong (at least 80-bit-key strength)
>
> (10) user-ready incl enough documentation to be used directly without doing
> programming, compilation etc
>
> (11) algorithm has some pedigree - i.e. has widespread degree of respect
> in the crypto community
>
> (12) implementation (inc. compilation) should have some pedigree - i.e. has
> widespread degree of respec
>
> -----------== Posted via Deja News, The Discussion Network ==----------
> http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
>
I think you can do no better in your request than SCOTT16U.ZIP it is
available world wide is free and the source code is included. However
it was written by me an outsider to the established crypto community
But it has no holes and is not a weak keyed method that you will most
likely end up using. It is very hard to find something strong. The more
posative press you see on a method the more like it is broken by the
NSA or such. You should run your on tests to check whatever you are using.
Good Luck
David Scott
http://cryptography.org/cgi-bin/crypto.cgi/Misc/scott19u.zip
http://members.xoom.com/ecil/index.htm
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: William Hugh Murray <[EMAIL PROTECTED]>
Subject: Re: newbie question
Date: Tue, 30 Mar 1999 15:19:31 GMT
This is a multi-part message in MIME format.
==============D8971E064B299DE784A6389B
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
All true, Kryspin. Indeed the function is not even secret; it is
public. You do not even need to deduce. It is also true that if you
have a copy of the public key and a message encrypted with the private
key, you have enough information to calculate the private key. What you
do not have is enough time.
Kryspin Ziemski wrote:
>
> fine still does not change the fact that ..
> hey you're polish, cool.. just noticed the pl in the ip address
> well fine assuming that you have the recipient's public key, you can find
> his private key
> by simply debugging the code and looking for the part that actually
> manipulates that public key
> to find the private key. how do you prevent this dilema which should occur
> because there is no way to hide the actual function from being observed on
> the byte level.
>
> Michal Brzozowski <[EMAIL PROTECTED]> wrote in message
> news:6w%L2.33449$[EMAIL PROTECTED]...
> >
> > Kryspin Ziemski wrote in message <[EMAIL PROTECTED]>...
> > >My understanding of public key cryptography is that each person is
> assigned
> > >to keys one private and one public. the sender encrypts the message with
> > >his private key and then sends the message to the reader.
> > >the reader gets the sender's public key from a directory and then
> converts
> > >the public key to the private key using some mathematical relation and
> > >decrypts the message using the private key. If this is how public key
> > >cryptography works what stops me obtaining the sender's public key and
> > >debugging the program to find the code that works on the public key to
> > >convert it to the private key which i'm assuming is done locally on the
> > >computer.
> >
> >
> > Wrong. Sender encrypts message with receipient's public key,
> > and receipient decrypts it using his (receipient's) private key,
> > Nobody (except owner) has access to private key.
> >
> > Michal Brzozowski
> > [EMAIL PROTECTED]
> >
> >
> >
==============D8971E064B299DE784A6389B
Content-Type: text/x-vcard; charset=us-ascii;
name="whmurray.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for William Hugh Murray
Content-Disposition: attachment;
filename="whmurray.vcf"
begin:vcard
n:Murray;William Hugh
tel;fax:800-690-7952
tel;home:203-966-4769
tel;work:203-966-4769
x-mozilla-html:FALSE
adr:;;;;;;
version:2.1
email;internet:[EMAIL PROTECTED]
fn:William Hugh Murray
end:vcard
==============D8971E064B299DE784A6389B==
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: Live from the Second AES Conference
Date: 30 Mar 1999 08:45:28 -0800
In article <[EMAIL PROTECTED]>, Jim Gillogly <[EMAIL PROTECTED]> wrote:
> > The authors show that A.B (encrypting with A first, then B second)
> > is at least as secure as A, but not necessarily as secure as B (under
> > some threat models, anyway -- in particular, under ciphertext-only
> > probable-plaintext attack, A.B might be weaker than B, if you are
> > especially unlucky).
>
> I'll check the reference. However, unless the two use related keys and
> the ciphertext of the first is distinguishable from random, I have yet to
> be convinced that applying B to A in this case doesn't constitute an
> attack on A that could be applied by the cryptanalyst who simply obtains
> A ciphertext. But I'll read the paper...
Here's the idea (intuition only, hope I remember this correctly).
Let S be the set of English-looking plaintexts, and suppose A maps S
to some other set T. It might happen that B is weak for encrypting T
but good for encrypting S. In this case, A.B would be weaker than B
is, for probable-plaintext attacks.
(I believe that if there is a probable-plaintext attack on A.B, then
there is necessarily a chosen-plaintext attack on B. But typically a
cipher that falls to probable-plaintext attacks is considered weaker
than a cipher which resists everything short of chosen-text attacks,
so this doesn't contradict the claim that A.B might be weaker than B.)
> > Also, one requires the assumption that A and B are keyed independently,
> > which raises the question: what key schedule should we use for A.B?
>
> The obvious suggestion to use each component's native key schedule.
Let me make sure I understand correctly. To encipher under E2.RC6
with a 128-bit key K, you first encrypt under E2 with the subkeys
determined by E2's key schedule applied to K, then encrypt under RC6
with the subkeys determined by RC6's key schedule on K?
If I am got that right, this doesn't work -- the two ciphers' keys
aren't independent. In fact, they're about as dependent as you
can get -- they're equal!
So the proof of security doesn't go through.
Using dependent keys somehow "voids the security warranty" provided
by the theoretical proofs...
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: Live from the Second AES Conference
Date: Tue, 30 Mar 1999 09:23:45 -0800
Reply-To: [EMAIL PROTECTED]
David Wagner wrote:
>
> Here's the idea (intuition only, hope I remember this correctly).
> Let S be the set of English-looking plaintexts, and suppose A maps S
> to some other set T. It might happen that B is weak for encrypting T
> but good for encrypting S. In this case, A.B would be weaker than B
> is, for probable-plaintext attacks.
Oh. I had assumed we were talking about modern general-purpose
ciphers rather than theoretical ciphers that were broken in
specific ways. I'm less interested in the latter, and will bow
out of the thread.
> > > Also, one requires the assumption that A and B are keyed independently,
> > > which raises the question: what key schedule should we use for A.B?
> >
> > The obvious suggestion to use each component's native key schedule.
>
> Let me make sure I understand correctly. To encipher under E2.RC6
> with a 128-bit key K, you first encrypt under E2 with the subkeys
> determined by E2's key schedule applied to K, then encrypt under RC6
> with the subkeys determined by RC6's key schedule on K?
My suggestion was that to use E2.RC6, where each of E2 and RC6 is to
be used in its 128-bit mode, you would need a 256-bit key, with all
256 bits independently chosen. E2 would use 128 bits, and RC6 would
use 128 bits, each using its own key schedule. I agree that 128-bit
E2.RC6 is not well-defined, and probably not desirable.
> If I am got that right, this doesn't work -- the two ciphers' keys
> aren't independent. In fact, they're about as dependent as you
> can get -- they're equal!
> So the proof of security doesn't go through.
I agree, and didn't intend this. I thought that's what <you> were
suggesting .
> Using dependent keys somehow "voids the security warranty" provided
> by the theoretical proofs...
Absolutely agree.
--
Jim Gillogly
Sterday, 8 Astron S.R. 1999, 17:18
12.19.6.1.3, 5 Akbal 16 Cumku, Fifth Lord of Night
------------------------------
From: "Alex" <[EMAIL PROTECTED]>
Subject: Re: strong brain-embedded decryption algorithm
Date: Tue, 30 Mar 1999 21:27:31 +0400
John Savard <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> [EMAIL PROTECTED] (DuBose8) wrote, in part:
> I guess they mean something a person can work out in his or her head, as
> opposed to something that has to use a computer - which might be bugged.
His or her brain might be bugged too.
------------------------------
From: Fiji <[EMAIL PROTECTED]>
Crossposted-To: sci.math.symbolic
Subject: Re: ---- Two very easy secret key Cryptosystems
Date: Tue, 30 Mar 1999 10:17:42 -0500
>
> a,b,c and e denote positive integers.
>
> Please crack the following systems:
>
> (Q1)
> plaintext: [a,b,c]
> encryption: choose a secret number e,
> cyphertext = [A,B,C] = [e*a, e*b, e*c]
> decryption: the partner know e,
> get plaintext [a,b,c]= [A/e, B/e, C/e]
>
Well if this were english text, it would be nothing but a substitution
cipher which would allow one to do frequency analysis. This is not unlike
the affine cipher.
-Fiji
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: True Randomness & The Law Of Large Numbers
Date: Tue, 30 Mar 1999 14:31:19 GMT
Reply-To: [EMAIL PROTECTED]
On Tue, 30 Mar 1999 09:16:45 GMT, Dave Knapp <[EMAIL PROTECTED]> wrote:
>Your great argument is based on _this_? That correlated measurements
>don't give the same answer as uncorrelated measurements?
>So you are claiming that true random numbers are correlated how?
You have just disclosed for all to see that you obviously do not have
a clue as to what we are discussing here. How on earth you can claim
that a uniform Bernoulli process is "correlated" is beyond me.
So that others will not possibly get confused by your deliberate
obfuscation (although I certainly do not know how anyone could be that
stupid), I point out that the random walk model is a way of depicting
bias in actual sequences. The distance a particle is from the origin
is a direct measure of the net excess of steps in one direction. The
fact that many particles do migrate away from the origin has
absolutely nothing to do with any "correlation".
Naive intuition attempts to confuse the time average of one sequence
with the ensemble average of the entire collection of sequences. It is
the latter that the law of large numbers addresses, not the former.
Any given sequence can (and for most sequences does) have terribly
"abnormal" statistical properties, yet the entire collection taken as
an ensemble has perfectly normal statistical properties, thanks to the
law of large numbers.
The problem then comes down to what size sample must one test
statistically to get a reasonably correct characterization of the
properties of a TRNG? If I am interested in the randomness of 10,000
bit sequences, how many such 10,000 bit sequences must I test in
aggregate before I can have some reasonable assurance that the TRNG is
not malfunctioning?
Since there are 2^10000 possible sequences in the phase space of this
generator (a number in base 10 so large my TI calculator can't compute
it), what fraction of those 2^10000 sequences must I test
statistically? Will 1% suffice? If so, then how can anyone reasonably
expect me to test 2^10000/10^2 sequences, which is still an impossibly
large number?
Put another way, how can anyone expect that testing even 1,000,000
sequences of length 10,000 bits ever hope to characterize the TRNG
correctly, even to some level of approximation. 1,000,000 sequences is
such as small fraction of the 2^10000 sequences in the ensemble that
such few sequences cannot ever possibly do a good job of representing
the ensemble reasonably well.
Bob Knauer
"What right does Congress have to go around making laws just because
they deem it necessary?"
- Marion Barry, Mayor of Washington DC
------------------------------
From: "Arthur N. Klassen" <[EMAIL PROTECTED]>
Crossposted-To: comp.security.misc
Subject: Re: Wanted: free small DOS Encryption program - rc4.exe (0/1)
Date: Tue, 30 Mar 1999 14:37:07 GMT
Frank Andrew Stevenson wrote:
> The following code was thrown together in a 15 minutes bout of anger
> after Norway accepted the latest Wassenaar list of controlled goods.
> I was just trying to find out how fast and easy it is to throw together
> something that will be considered unexportable.
The other option is to look at ciphersaber.gurus.com and write your own!
This form of RC4 includes the initialization vector that our Norwegian
colleague bemoaned having left out. His warning about multiple files
with the same password should be taken seriously. Also, whatever you
encrypt, unless it is already compressed (e.g. GIFs or JPEGs) you may
want to zip it up first. This could be done in a batch file or by
including some free zip source code in your product.
cheers...ank
--
[EMAIL PROTECTED] | The word "mercy"'s gonna have a new meaning
<*> | +t+ -> | |0 !! | when we are judged by the children of our slaves
PGP: **** 2047/DCDF9341:E273 AD0E F99A 8869 050B 5E92 0E47 C151 **** two
finger- *** 30DF 376C 43D0 DA74 F33F 752C 192E 3711 5E52 02BF *** prints
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: Random Walk
Date: Tue, 30 Mar 1999 16:29:16 GMT
Reply-To: [EMAIL PROTECTED]
On 30 Mar 1999 10:05:47 -0500, [EMAIL PROTECTED] (Herman
Rubin) wrote:
>>Exactly what statistical tests do you plan to conduct on that
>>keystream that you believe will tell you that the TRNG is
>>malfunctioning?
>If you define functioning
We have been discussing the uniform Bernoulli process (UBP) and its
close cousin, the uniform random walk in one dimension.
My purpose in discussing all this is twofold:
1) To point out how abnormal the statistical properties of many truly
random sequences are (cf. Feller, and Li & Vitanyi, op. cit.);
2) To decide if the UBP is a correct model for an idealized TRNG for
purposes of generating crypto-grade random numbers.
The fact that we cannot ever hope to build a real-world TRGN that is
exactly like the idealized one discussed here should not deter us from
investigating the idealization. After all, if that were the modus
operandi of mathematics, we would have no mathematics, since the
objects of mathematics are all idealizations themselves.
So consider this a "meta-mathematical" discussion of True Randomness
if you want.
> as meaning that the sequence of bits is independent,
I would also require that the sequences be equidistributed.
But then, that is what is meant by term "uniform", namely
equidistribution, so it is a bit redundant for the UBP.
>with each bit being equally likely to be zero or
>one, my answer is that the TRNG is malfunctioning, and I do not
>need to perform a test.
We are currently discussing an idealized TRNG, one that is modeled by
a UBP.
For such a TRNG, tell us exactly what statistical tests you plan to
conduct on the keystream that you believe will tell you that the TRNG
is malfunctioning. We seem to have agreed earlier that you can never
conduct statistical tests which will tell you that a TRNG is truly
random, so the only hope is that such tests will tell you that is it
NOT truly random.
I believe that the latter is a hopeless task too, since the only way
you can know with reasonable certainty that a TRNG is not truly random
for large size sequences is to test an impossibly large ensemble.
>Physical equipment is not going to preform in an ideal manner.
You might want to catch up on the advances in quantum computing. For
example, in Williams & Clearwater's book (op.cit.) they state:
"... a classical computer can only *pretend* to generate a random
number whereas a quantum computer can *actually* generate a random
number."
Such a quantum computer is necessarily a piece of physical equipment.
>Far too many believe, and have believed, that the point null
>hypothesis is tenable. Even when it is, it is something about
>a law of nature, not a realizable experiment.
I just looked up the term "point null hypothesis" in both volumes of
William Feller's monumental work on probability, 3rd ed. (op. cit.). I
cannot find it. Is there another term that is used to describe it? If
not, please explain what you mean by that term.
In addition to your statement, I would add this: Far too many believe,
and have believed, that the a time average for a given sequence in a
uniform Bernoulli process is the same as the ensemble average for that
process. For example, people erroneously believe that just because
half the sequences in an ensemble of size 2^n have positive bias and
half have negative bias and therefore the ensemble average shows no
net bias, that each individual given sequence must also exhibit zero
bias or near zero bias. The exposition of writers like Feller point
out that such is not the case.
Unbiased (or nearly unbiased) sequences are possible only for
sequences of infinite length, where Borel normality is the rule. For
sequences of finite length, albeit large finite length, that is not
possible since many sequences have significant 1-bit bias.
The fact is that many sequences of length n in an ensemble of 2^n such
sequences are highly abnormal (highly biased) compared to n. Feller
gives several examples of just how abnormal they are using
straightforward combinatorial analysis.
Bob Knauer
"The laws in this city are clearly racist. All laws are racist.
The law of gravity is racist."
- Marion Barry, Mayor of Washington DC
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Encryption and the Linux password files
Date: Tue, 30 Mar 1999 18:00:39 GMT
"Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote, in part:
>John Savard wrote:
quoting somebody:
>> >Any box with a competent sys admin has a shadowed passfile, and not
>> >simply the default /etc/password.
>> True, and the default password file has to exist for compatibility reasons
>> with some old database software that uses it to find users...
>But the password file doesn't contain the (encrypted) passwords
>when shadowing is used.
Yes, I realize that. But if it weren't for these compatibility problems,
the original password file could be abolished, thus eliminating the option
- the default option - of doing without a shadow password file. (Although,
for some users, running Unix as if it were DOS - with no passwords or login
IDs - just turn on the box, and you're in root - may make perfect sense, if
one is going to make using passwords compulsory, one might as well use a
system that works...)
John Savard (teneerf is spelled backwards)
http://members.xoom.com/quadibloc/index.html
------------------------------
From: [EMAIL PROTECTED] (Patrick Juola)
Crossposted-To: comp.security.misc
Subject: Re: Wanted: free small DOS Encryption program
Date: 30 Mar 1999 10:06:18 -0500
In article <7dqoa9$hqi$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
>In article <7dpqev$ovj$[EMAIL PROTECTED]>,
> Milton Pomeroy <[EMAIL PROTECTED]> wrote:
>> Wanted - a free DOS-based encryption program which is small, fast,
>> strong and friendly
>>
>> Explanation
>>
>> I want recommendations of encryption software to store small amounts of
>> sensitive information (up to 30kbytes) for my own use - i.e. I encrypt it,
>> and I decrypt it. Since I plan to carry the encrypted datafile and
>> encryption software on floppy disk and use it on various PCs (some of which
>> may not be owned by me), I plan to use it from DOS (don't want to load it on
>> PC, don't want any temporary decrypted data left on the PC's hard-disk). The
>> PCs will be running DOS, Win95/8, or WinNT. Typically, I'd run it from the
>> floppy in a DOS-Window.
>>
>> The mandatory requirements therefore are:
>>
>> (1) runs from DOS (and DOS-prompt in a DOS-Window)
>>
>> (2) freeware/public domain
>>
>> (3) be accessible to someone (like me in Australia) who is outside USA
>> (no export restrictions)
>>
>> (4) works in 450kBytes or less of RAM
>>
>> (5) already compiled i.e. an EXE or COM version is available
>> (I don't want the uncertainty of my doing a poor compilation
>> resulting in a poor security implementation)
>>
>> (6) EXE or COM file must be small - less than say 80kbytes
>> (if it's large, like PGP for DOS at around 400kbytes, it takes
>> over 10sec to load from floppy-drive)
>>
>> (7) fast execution - less than say 5 seconds to load from floppy
>> and complete encryption/decryption of up to 30kBytes of data
>> on a 486-66
>>
>> (8) can run from a floppy with any temporary files being stored on the
>> floppy
>>
>> (9) strong (at least 80-bit-key strength)
>>
>> (10) user-ready incl enough documentation to be used directly without doing
>> programming, compilation etc
>>
>> (11) algorithm has some pedigree - i.e. has widespread degree of respect
>> in the crypto community
>>
>> (12) implementation (inc. compilation) should have some pedigree - i.e. has
>> widespread degree of respec
>>
>> -----------== Posted via Deja News, The Discussion Network ==----------
>> http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
>>
>
>
> I think you can do no better in your request than SCOTT16U.ZIP it is
>available world wide is free and the source code is included. However
>it was written by me an outsider to the established crypto community
... and has not had any sort of serious security analysis. Furthermore,
previous versions of this algorithm were shown to be extremely easy
to break by Paul Onions.
I strongly recommend you *NOT* use this algorithm on any data you want
to keep secure.
-kitten
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Live from the Second AES Conference
Date: Tue, 30 Mar 1999 16:27:01 GMT
Jim Gillogly <[EMAIL PROTECTED]> wrote, in part:
>David Wagner wrote:
>> You might want to check out
>> ``Cascade Ciphers: The Importance of Being First''
>> in J. Cryptology vol. 6 1993 pp. 55--61.
>I'll check the reference. However, unless the two use related keys and
>the ciphertext of the first is distinguishable from random, I have yet to
>be convinced that applying B to A in this case doesn't constitute an
>attack on A that could be applied by the cryptanalyst who simply obtains
>A ciphertext. But I'll read the paper...
But it could be an attack on B - basically, as I understood how this work
was cited in Applied Cryptography (Bruce Schneier), the paper shows that
the first cipher can weaken the second one if it is designed to introduce
known plaintext, additional redundancy, or things like that. If one feels -
for example, as the implementor of both ciphers - that this is not a real
worry, then one has gained security from a cascade. (But notice too that AB
might be subject to the same attack as double-DES, so one may really want
ABC.)
John Savard (teneerf is spelled backwards)
http://members.xoom.com/quadibloc/index.html
------------------------------
From: Doggmatic <[EMAIL PROTECTED]>
Subject: Re: Testing Algorithms [moving off-topic]
Date: Thu, 25 Mar 1999 07:32:18 GMT
In article <7cj272$j05$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Patrick Juola) wrote:
> It's not. Reach a good calculus book sometime about the theory of limits
> and get back to me when you understand the idea of asymptotic approximation.
>
> -kitten
>
A concept I'm well-familiar with, though you never before mentioned
"nearly"-reversible computing. I've been reading about reversible circuits
which would kill the energy argument. Yippie. One down one to go. How do
you propose to circumvent the time/memory constraint?
___/Mike ...two legs good, four legs bad? ... Why conform?
__/. |
\-__ \___
\
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Does anyone know how to solve vigenere and tranposition cipher?
Date: Tue, 30 Mar 1999 16:38:13 GMT
"colgates" <[EMAIL PROTECTED]> wrote, in part:
>Hi I need help from anyone who know how to decipher tranposition and
>vigenere/Beaufort cipher.
>I got a ciphertext but no sure how to decipher them. Please help. Thanks.
Well, for Vigenere or Beaufort, there are two things you can do:
look for repeated strings in the text, and find the displacement between
them.
ABCMZXVABC has a displacement of 7; you want the exact offset;
and any number which is the largest common factor of nearly all the
displacements should be the period. Then it becomes only a little harder
than a monalphabetic. (If it is really Vigenere or Beaufort, with standard
alphabets, it is easier.)
Failing that, slide the message against itself, finding when the number of
individual letter matches is higher.
For transposition, the methods are more complicated. Try
http://www.und.nodak.edu/org/crypto/crypto/
(The Crypto Drop Box) for some information.
John Savard (teneerf is spelled backwards)
http://members.xoom.com/quadibloc/index.html
------------------------------
** 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
******************************
