Cryptography-Digest Digest #904, Volume #10 Fri, 14 Jan 00 12:13:02 EST
Contents:
Re: Double transposition/playfair (UBCHI2)
Re: AES & satellite example ([EMAIL PROTECTED])
Re: RSA (Bob Silverman)
Re: "1:1 adaptive huffman compression" doesn't work (Mok-Kong Shen)
Re: "1:1 adaptive huffman compression" doesn't work (Mok-Kong Shen)
Re: UK Government challenge? (Richard Herring)
Re: AES & satellite example ("Trevor Jackson, III")
Re: AES & satellite example (Frank Gifford)
Re: Ciphers for Parallel Computers (John Savard)
Re: Intel 82802 Random Number Generator (Guy Macon)
Re: UK Government challenge? ("Tim Wood")
Re: Truly random bistream (Guy Macon)
Re: New Crypto Export Regs (Kent Briggs)
SRP optimisation (Keith Burdis)
Re: Blum, Blum, Shub generator (Kent Briggs)
Re: GPS coding (was: LSFR) (John Myre)
Re: Wagner et Al. (Guy Macon)
Re: Why is EDI dead? Is S/MIME 'safe'? Who and why? (sb5309)
Re: encryption/decryption programs ("Tim Wood")
Re: Why is EDI dead? Is S/MIME 'safe'? Who and why? (sb5309)
Re: Ciphers for Parallel Computers (Tim Tyler)
Re: Little "o" in "Big-O" notation (Mike McCarty)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (UBCHI2)
Subject: Re: Double transposition/playfair
Date: 14 Jan 2000 15:13:38 GMT
But playfair 2x still will fall to frequency analysis of the digraphs. The
second playfair round preserves digraph frequencies albeit with different
letters. Yes?
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: AES & satellite example
Date: Fri, 14 Jan 2000 15:06:41 GMT
In article <[EMAIL PROTECTED]>,
"Trevor Jackson, III" <[EMAIL PROTECTED]> wrote:
> Opportunistic enhancements to federal standards are few and far
between.
Why do you say this? NIST enhanced SHA as soon as it found a flaw.
> If NIST picks one cipher
> we're probably going to be stuck with it for decades.
We should be so lucky. If NIST picks a cipher that is
commercially useful for decades, then it will be a
remarkable success. That is part of why standards are good.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Bob Silverman <[EMAIL PROTECTED]>
Subject: Re: RSA
Date: Fri, 14 Jan 2000 15:06:33 GMT
In article <387f285f$0$[EMAIL PROTECTED]>,
"Kreuzer Michael" <[EMAIL PROTECTED]> wrote:
> Hello,
>
> i have a big big problem. i must decode a rsa code. its my homework
*g* can
> anyone help me?
>
> the code :
>
> key : 51,3
>
> 616
> 591
<snip>
I don't understand your format. Are you saying the modulus is 51,
and the public exponent is 3?
What is
616
591
.
.
etc? Generally, the ciphertext will consist of a set of numbers
SMALLER than the modulus. But these numbers are greater than 51!
--
Clarify.
Bob Silverman
"You can lead a horse's ass to knowledge, but you can't make him think"
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: "1:1 adaptive huffman compression" doesn't work
Date: Fri, 14 Jan 2000 16:32:48 +0100
SCOTT19U.ZIP_GUY wrote:
>
> In article <[EMAIL PROTECTED]>, Mok-Kong Shen <[EMAIL PROTECTED]>
>wrote:
> >Tim Tyler wrote:
> >>
> >> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> >>
> >> : My proposal is able to satisfy the requirement you
> >> : originally raised, i.e. to give the analyst no information via
> >> : the decompression-(re-)compression process.
> >>
> >> Which it would do reasonably well, /if/ you could get hold of some "real"
> >> random numbers. Getting hold of them in a portable way would be better
> >> still.
> >
> >I have explained in a previous follow-up that one needs only
> >'non-constancy'. Here is a repetition: Suppose the decrypted
> >compressed file is uncompressed and compressed again. The two
> >files can be compared to easily find out the filling bits. Suppose
> >the old and new filling bits are 00 and 11 respectively. What
> >information does the analyst get from that? He knows that if, for
> >example, he contitunes to do uncompress-compress he will get
> >in most cases different filling bits. So from these filling bits
> >he knows nothing. If you don't agree with this, please kindly show
> >where my argument is wrong with details. Simply claiming that it
> >doesn't work or doesn't work well is not sufficient.
> >
>
> if you have two filling bits. And if you assume the person decodeing
> has the compression programns he can just ignore the filling bits during
> the comparsions. That way the person trying to break the code can really
> just ignore them.
How many filling bits are there depends on the plaintext (or the
'presumed' plaintext if the analyst uses a wrong key). Yes, any
one, whether the receiver or the analyst, ignores these (or rather
the processing software ignores these). The point is that, because
they all ignore these, any difference in the filling bits is
immaterial. (The other way round to look at this is of course
the repeatedly said fact that the filling bits are 'arbitrary',
being willy-nilly chosen by the software at an arbitrary occassion,
and hence have no 'meaning'.) That is the gist of the proposed
scheme. Otherwise the scheme wouldn't function.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: "1:1 adaptive huffman compression" doesn't work
Date: Fri, 14 Jan 2000 16:32:38 +0100
SCOTT19U.ZIP_GUY schrieb:
>
> In article <[EMAIL PROTECTED]>, Mok-Kong Shen
><[EMAIL PROTECTED]> wrote:
> >SCOTT19U.ZIP_GUY schrieb:
> >>
> >> In article <[EMAIL PROTECTED]>, Mok-Kong Shen
> > <[EMAIL PROTECTED]> wrote:
> >> >SCOTT19U.ZIP_GUY wrote:
> >> >>
> >> >> <[EMAIL PROTECTED]> wrote:
> >
> >> >> >least theoretically more satisfying) products. But on retrospect,
> >> >> >if my proposal were put forth earlier, there would be in my humble
> >> >
> >> >> What humble opinion
> >> >
> >> >If you consider modesty is bad, then substitute it with 'my high
> >> >opinion'. o.k. for you now??
> >>
> >> I don't consider modesty bad. I consider false modesty bad.
> >
> >What do you mean false modesty here? I don't absolutely exclude that's
> >because I am not a native English speaker. But to my best knowledge
> >there is nothing 'particular' implied in the 'courtesy' words in
> >phrases like 'yours sincerely', IMHO, etc. etc. Look at what the French
> >people write when they end their letters!! On the other hand, I find
> >those (not infrequent) posts on the internet that contain bad words
> >(swear-words) simply horrible.
> >
>
> Well Mr Mok that life.
Sorry, my English knowledge doesn't enable me to 'decode' that
sentence. Anyway, the syntatic analysis I learned from school
does not suffice to anylyse that. I don't see, among others
which word is the verb. Pardon.
Perhaps I may take this opportunity to ask those in this group
who are native speakers in the English language to take into
consideration that the (poor) foreigners may have difficulties
to comprehend if sentences they write deviate from the common
'standard' types according to grammar that one learns in schools.
Thanks.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (Richard Herring)
Subject: Re: UK Government challenge?
Date: 14 Jan 2000 15:35:47 GMT
Reply-To: [EMAIL PROTECTED]
In article <[EMAIL PROTECTED]>, Douglas A. Gwyn ([EMAIL PROTECTED]) wrote:
> John Savard wrote:
> > Their site must be busy...
> The actual GCHQ challenge starts at
> http://www.gchq.gov.uk/challenge.html
Looks more like steganography than crypto to me.
My problem with identifying the five groups of five characters
hidden somewhere on the site is that I can't tell whether any
oddities are clues, or just symptoms of incompetent web design :-(
--
Richard Herring | <[EMAIL PROTECTED]>
------------------------------
Date: Fri, 14 Jan 2000 11:00:21 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: AES & satellite example
[EMAIL PROTECTED] wrote:
> In article <[EMAIL PROTECTED]>,
> "Trevor Jackson, III" <[EMAIL PROTECTED]> wrote:
> > Opportunistic enhancements to federal standards are few and far
> between.
>
> Why do you say this? NIST enhanced SHA as soon as it found a flaw.
Your example supports the point I was making, which is that we should
expect the standard to be improved only to correct faults and not when
an improvement is available.
> > If NIST picks one cipher
> > we're probably going to be stuck with it for decades.
>
> We should be so lucky. If NIST picks a cipher that is
> commercially useful for decades, then it will be a
> remarkable success. That is part of why standards are good.
And is NIST picks a cipher that is not useful for decades it will still
be a standard for decades. Which would be a predictable, thus aver
table, disaster. That is part of why (poorly chosen) standards are bad.
------------------------------
From: [EMAIL PROTECTED] (Frank Gifford)
Subject: Re: AES & satellite example
Date: 14 Jan 2000 10:52:10 -0500
In article <[EMAIL PROTECTED]>, Nicol So <see.signature> wrote:
>At this point, somebody may wonder how we're going to secure the
>replacement algorithm against tampering. I'll just say it can be done
>and it's not that hard. And it doesn't need to rely on crypto algorithms
>of unknown strength.
Here are some assumptions:
- There is a (military) satellite which gathers information itself and needs
to send information back to the planet.
- That information must be encrypted to prevent eavesdropping. (Also, it
would be nice to have some authentication of the message being sent back).
Risk:
- The onboard cipher may become compromised in the future. (Via a spy who
discloses the algorithm, analysis of ciphertext by the opponent or other
advancement by crypto-community).
Requirements:
- The onboard algorithm needs to be able to be replaced.
- The satellite needs a way to verify that it should use a new cipher (i.e.
it has to authenticate the message from the ground).
- The cipher algorithm itself ought to be sent such that it isn't known
to the opponent. (Although Kerckhoff's 3rd maxim comes into play - one
doesn't have to give the algorithm to the opponent!)
- This process may have to be done repeatedly.
It seems that there needs to be some sort of other cipher which is only
used for uploading/downloading of the new algorithm. Alternatively,
there can be an RSA type encryption - in which case the security is
based on the strength of RSA.
Can you give me a hint about the fast and secure replacement method which
can handle these requirements?
>> Having multiple ciphers as backups is almost certainly a good idea as long
>> as they are all believed to be strong, and there is a way to securely tell
>> the satellite to stop using a given cipher.
>
>If you want to argue for a position by drawing on real-life examples, it
>helps to verify that your premises are indeed true.
Well, I haven't done work with satellites and this type of problem. My
thoughts on this are trying to noodle things through.
-Giff
--
Too busy for a .sig
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Ciphers for Parallel Computers
Date: Fri, 14 Jan 2000 15:45:50 GMT
On Fri, 14 Jan 2000 10:28:27 +0100, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:
>But I don't yet
>clearly see an advantage that pertains to only one side of the
>antagonist pair user-analyst. Higher speed can be of 'advantage' to
>both sides.
Basically, because a cipher must be invertible, most typical
encryption algorithms do not parallelize well. (Of course, if one uses
an encryption mode that lets you encipher the different pieces of a
message independently, one can also solve this problem.)
Thus, if the cryptographer, in a future world where the typical
microchip has 1024 processors on it, just makes use of one of them,
while the cryptanalyst can use every one (since brute-force searching,
at least, does parallelize excellently) then there is a one-sided
advantage.
John Savard (teneerf <-)
http://www.ecn.ab.ca/~jsavard/index.html
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Intel 82802 Random Number Generator
Date: 14 Jan 2000 11:06:59 EST
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (David Hopwood)
wrote:
>> If (questionable assumption!) the *only* bias was an adjacent
>> bit correlation of the input bits to the Von Nuemann rejector,
>> the output bits would be unbiased.
>
>That's not correct. An input that alternates between 0 and 1
>will produce an output from the rejector containing long (or
>at least longer than expected) stretches of 0s or 1s.
But that would imply a corrolation between a bit and a bit
two positions away, which contradicts what I said about the
only bias being an adjacent bit correlation. Of course if
there is a corrolation with an adjacent bit and that adjacent
bit has a corrolation with the next bit. there is a a corrolation
between a bit and a bit two positions away. This, among other
reasons, is why I called it a questionable assumption. The
only way to get only adjacent bit correlation is to have pairs
of bits corrolated with each other but not with other pairs of
bits. A questionable assumption indeed!
------------------------------
From: "Tim Wood" <[EMAIL PROTECTED]>
Subject: Re: UK Government challenge?
Date: Fri, 14 Jan 2000 16:18:23 -0000
I'm told one of the letter groups is in morse code ;-) but your right, I
think it is steganography...
The news article at
http://news.bbc.co.uk/hi/english/uk/newsid_601000/601960.stm
is worth reading though, it contains some quotes from David Shayler and
others...
tim
"Richard Herring" <[EMAIL PROTECTED]> wrote in message
news:85nfoj$9ma$[EMAIL PROTECTED]...
> In article <[EMAIL PROTECTED]>, Douglas A. Gwyn ([EMAIL PROTECTED])
wrote:
> > John Savard wrote:
> > > Their site must be busy...
>
> > The actual GCHQ challenge starts at
> > http://www.gchq.gov.uk/challenge.html
>
> Looks more like steganography than crypto to me.
>
> My problem with identifying the five groups of five characters
> hidden somewhere on the site is that I can't tell whether any
> oddities are clues, or just symptoms of incompetent web design :-(
>
> --
> Richard Herring | <[EMAIL PROTECTED]>
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Truly random bistream
Date: 14 Jan 2000 11:17:01 EST
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Tim Tyler) wrote:
>
>Guy Macon <[EMAIL PROTECTED]> wrote:
>: In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Tim Tyler) wrote:
>
>:>Nobody can measure resistance with the accuracy required. It takes
>:>time to measure resistance. The more accurate you want to be, the
>:>longer you have to observe for. Without measurement, you can't
>:>confirm the resistance of the entity in question to the satisfaction of
>:>anyone else.
>
>: Would a superconducting ring with a current going round and round
>: for months or years be good enough for you? Got that. Would a
>: magnetic field measurement an one day equalling one at six months
>: being as close as we can measure help? Got that too.
>
>No, none of these things would be good enough for me. Resistance
>mesaurements may get more accurate with time, but for *infinite* accuracy,
>you would appear to need infinite time.
>
>It appears that as nature abhors a vacuum, so science abhors certainty.
>At no point can you say that your equipment is offering zero resistance,
>or was doing so at any particular time in the past - you have no certain
>way of knowing what it's doing.
>
>It is much the same as with random numbers. You can apparently construct
>patterns with arbitrarily high entropy-ber-bit contents, and that appear
>to observers to have no detectable pattern - the equivalent of currents
>circulating for large periods of time - but you'll never actually obtain
>"true" randomness.
I agree. My only quibble is that it appears that some physical systems
can be shown to have quantum states. If quantum theory is true and your
physical system exibits quantum effects, then I think that you can
detect zero in a finite amount of time. Then again, the line of argument
that I am using is full of pitfalls, snags, and detours that even I, a
clueless newbie, can see.
------------------------------
From: Kent Briggs <[EMAIL PROTECTED]>
Subject: Re: New Crypto Export Regs
Date: Fri, 14 Jan 2000 16:13:14 GMT
"John E. Kuslich" wrote:
> Anyone know where to find the "New" crypto export rules released today??
>
> I looked at the BXA site and they seem to have not heard about crypto.
The official BXA site is here:
http://www.bxa.doc.gov/Encryption/Default.htm
--
Kent Briggs, [EMAIL PROTECTED]
Briggs Softworks, http://www.briggsoft.com
------------------------------
From: Keith Burdis <[EMAIL PROTECTED]>
Crossposted-To: sci.crypt.research
Subject: SRP optimisation
Date: 14 Jan 2000 16:12:30 -0000
Hi there
I'm not sure how many people here are familiar with Tom Wu's Secure Remote
Password (SRP) protocol, but maybe someone here can answer this. SRP
documentation is available at:
http://srp.stanford.edu/srp/doc.html
Looking at Optimized SRP described in Tom Wu's ISOC paper on SRP, Table 6
shows the message rounds as follows:
C --> S: C,A
C <-- S: s,B
C --> S: M1
C <-- S: M2
where:
M1 = H(A,B,K)
M2 = H(A,M1,K)
As noted, three messages is the lower bound for a secure authentication
protocol, but would it not be possible to have:
C --> S: C,A
C <-- S: s,B,M2
C --> S: M1
where:
M1 = H(B,M1,K)
M2 = H(A,B,K)
This allows mutual authentication to take place in three rounds instead of
four.
Can anyone see any problems with this?
Does having the server send its evidence first adversely affect the
security of SRP in any way?
Thanks.
- Keith
--
Keith Burdis - MSc (Computer Science) - Rhodes University, South Africa
IRC: Panthras JAPH QEFH
------------------------------
From: Kent Briggs <[EMAIL PROTECTED]>
Subject: Re: Blum, Blum, Shub generator
Date: Fri, 14 Jan 2000 16:22:26 GMT
Terry Ritter wrote:
> On the contrary: Worry about cycle lengths is fundamental to security
> in (conventional) stream cipher usage: If we use a cycle which repeats
> quickly, the system is insecure, no matter how impossible it may be to
> factor N.
FYI: The reason I was asking about the BBS period was not to ensure that it
was long but to know exactly what is was for a given pq. The equation to jump
forward in the BBS stream is relatively simple but the equation to jump
backwards is more complicated and involves an extended Euclidean calculation.
If the exact period was known, I thought it would be an easier calculation to
jump forward period - 1 steps than to go backwards 1 step. But based on the
comments here, the period is not easy to calculate so that kills that idea.
--
Kent Briggs, [EMAIL PROTECTED]
Briggs Softworks, http://www.briggsoft.com
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: GPS coding (was: LSFR)
Date: Fri, 14 Jan 2000 09:12:11 -0700
Terje Mathisen wrote:
...
> Since the [GPS] receivers know the 32 (?) possible spreading codes
...
I don't know how many codes are possible, but the last time I
knew, 37 codes were defined. Only 32 are used in on-orbit
satellites; there is a 5 bit field somewhere that identifies
the code, and also identifies the satellite. The rest of the
codes are used on the ground for testing.
(As you say, the data rate is very low; in addition to the
coding stuff, the raw data has a lot of repetition and 6
out of every 30 bits are parity. So there are a lot of quirks
like having only 5 bits to identify the satellite. And
actually, I'm not so sure that code 0 is used, either.)
John M.
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Wagner et Al.
Date: 14 Jan 2000 11:28:01 EST
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Paul
Crowley) wrote:
>
>[EMAIL PROTECTED] (Guy Macon) writes:
>> If someone has physical access to your computer (a requirement for
>> the attack you listed), NT is exactly the same level of security
>> as UNIX, Linux. OS/2, DOS, Mac OS, etc. None. Not a bit. Nada.
>> Don't even go there. That Dog won't hunt. NOT!! Null. Snowball's
>> chance in Hell. Fat chance. Slim chance. Don't hold your breath.
>
>Not strictly so. First, you can password-lock the BIOS into booting
>from the HD and padlock the case shut, in which case you'll need a
>pair of cutters to do the obvious attack, and you'll look a bit
>conspicuous using them.
Sounds like physical security to me.
> Second, Linux (at least) offers you the
>option of using encrypting filesystems, which means that even after
>you reboot you can't get at or usefully modify any of the data stored.
Windows 2K is promising to offer an encrypting filesystem as well.
This would make it MUCH harder to crack for someone with physical
access, so I retract the above statement. This does have an
interesting ramification - where is the decryption key? If it is in
your head, then you have to enter it into the computer at least once
before accessing the encrypted filesystem. Most NT servers are set
up to run all services at boot without human intervention. If the
key is on the disk somewhere, that could be the place to attack.
a challenge/response through the network might be a good answer.
A sophisticated attacker will be able to read and modify RAM
contents on the fly, which opens a whole new world of
vulnerabilities that an encrypting filesystem doesn't address.
--
"We don't have walls or fences, so why would we want Windows or Gates?"
------------------------------
From: sb5309 <[EMAIL PROTECTED]>
Crossposted-To: comp.security.misc,alt.security.pgp
Subject: Re: Why is EDI dead? Is S/MIME 'safe'? Who and why?
Date: Sat, 15 Jan 2000 00:32:31 +0800
Thanks, James.
> | What is "remote document processing business - invoices, price-lists,
> | technical drawings etc." ?
> |
> | I am curious. Thanks.
>
> It's part of remote publishing which can be for a reason of 'logistics'. For
> example, 'USA Today' has been operating multiple printing plants across the US
> to print their nationally-distributed paper near where it is to be delivered.
> You can access your corporate WAN and print documents at any office in the
------------------------------
From: "Tim Wood" <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.labview
Subject: Re: encryption/decryption programs
Date: Fri, 14 Jan 2000 16:37:16 -0000
"Tim and Carolyn" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Hello,
>
> Lately I've been reading a fascinating book by David Kahn called the
> "Codebreakers", and decided to try my hand at it. I wrote a little
> LabVIEW program that can encrypt text or binary files and save it to a
> new file. Files can be multiply encrypted with different passwords.
> There is also a decryption program.
>
> Is it any good? Beats me. I'm not a cryptanalyst. However, it was fun
> to work on over the break. The software can be found on my Web site at
> (diagrams are removed so you can't peek at my code):
>
> http://www.cs.wcupa.edu/~tstarn/software.html
>
You really should release the code (or at a minimum the algorithm) if you
want any serious work done on it.
Generally an algorithm's security is considered on the basis of the only
secret being the key. (i.e the algorhthim is known - and in most cases
plaintext-ciphertext pairs). An algorithm is generaly even supposed to
resist (within reason) releasing the key when the analyist can choose what
plaintext to encrypt.
A (good) book which seems to be read as standard by cryptographers is
Applied Cryptography by Bruce Schneier.
Have fun.
tim w
> Cheers,
>
> TKS
>
------------------------------
From: sb5309 <[EMAIL PROTECTED]>
Crossposted-To: comp.security.misc,alt.security.pgp
Subject: Re: Why is EDI dead? Is S/MIME 'safe'? Who and why?
Date: Sat, 15 Jan 2000 00:41:34 +0800
Oh, thanks Anne !
> | What is "remote document processing business - invoices, price-lists,
> | technical drawings etc." ?
> |
> | I am curious. Thanks
>
> there are printer outsourcers with locations around the country ...
> that are used by lots of industries ... including computer software
> vendors; somebody can call their vendor of choice and order a manual;
> the request is routed to the printing plant closest to the requester
> ... and the manual is printed "just in time" and shipped directly to
> the requester.
>
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Ciphers for Parallel Computers
Reply-To: [EMAIL PROTECTED]
Date: Fri, 14 Jan 2000 16:44:34 GMT
John Savard <[EMAIL PROTECTED]> wrote:
: Basically, because a cipher must be invertible, most typical
: encryption algorithms do not parallelize well.
I don't see that much of a connection. Certainly there seems to be no
/necesary/ connection between invertability and serial operation.
I /do/ see some connection between security generated by iterated
confusion sequences, and serial operation, though.
In some respects, /enforced/ serial operation (i.e. operations which it
is simply not possible to efficiently parallelise) is desirable, since
it forces the attacker to perform operations in sequence as well.
: (Of course, if one uses an encryption mode that lets you encipher
: the different pieces of a message independently, one can also solve
: this problem.)
That is true. Encyphering the message in larger chunks can also
help with parallel operation.
: Thus, if the cryptographer, in a future world where the typical
: microchip has 1024 processors on it, just makes use of one of them,
: while the cryptanalyst can use every one (since brute-force searching,
: at least, does parallelize excellently) then there is a one-sided
: advantage.
I'd have thought programmable logic means this is true today.
I'm interested in building hardware cypher machines.
I generally work with cellular automata.
There's a Java applet demonstrating briefly how scalable reversible
systems may be constructed - without recourse to the use of a Feistel
network - at http://alife.co.uk/diffusion/
You can run the automta forwards and backwards from user-configurable
states by clicking a checkbox, to verify the invertability.
In the text beneath this is a (very) breif description of the
form of one possible cryptographic application.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
Destroy Microsoft.
------------------------------
From: [EMAIL PROTECTED] (Mike McCarty)
Subject: Re: Little "o" in "Big-O" notation
Date: 14 Jan 2000 16:46:04 GMT
In article <[EMAIL PROTECTED]>, Anton Stiglic <[EMAIL PROTECTED]> wrote:
)Mike McCarty wrote:
)
)> In article <8591f5$u8v$[EMAIL PROTECTED]>,
)> Scott Fluhrer <[EMAIL PROTECTED]> wrote:
)> )
)> )Jeff Moser <[EMAIL PROTECTED]> wrote in message
)> )news:858nb6$bdo$[EMAIL PROTECTED]...
)> )> What exactly does the little "o" in "Big-Oh" notation mean? For example, I
)> )> know that o(1) becomes negiligible as the integer approaches infinity. I'm
)> )> uncertain on how to define it.
)> )
)> )o(f(x)) = g(x) is true iff:
)>
)> [snip]
)>
)> One of the rules for use of o(.) and O(.) is that neither of them is
)> permitted to appear on the left hand side of an equal sign.
)
)That is not true in the general sens as you have stated, because
)the following is a valid definition:
) o(g(n)) = {f(n): for any positivie constant c>0, there exists a constant
) n_0 > 0 such that 0 <= f(n) < c*g(n) for all n >=
)n_0}
I have never seen O and o used as the names for *sets*. It would not be
consistent with
f(x) = x^2 + O(1/x)
unless f(.) were somehow promoted to a set as well.
)and the o notation is on the left ;)
)One thing that is true is that something like
) f(x) = o(g(n)) is wrong,
This is the only way I have seen it used (except that using 'x' on the
LHS and 'n' on the RHS seems odd, perhaps a typo).
)you sould write
) f(x) is an element of o(g(n)) since o(g(n)) is a set.
)o(f(x)) = g(x) also doesn't make sens, as what was ment to be said in
)the quote above...
This flies in the face of every use of 'o' and 'O' I have seen.
Maybe usage is changing?
--
----
char *p="char *p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
I don't speak for Alcatel <- They make me say that.
------------------------------
** 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
******************************
