Cryptography-Digest Digest #943, Volume #13 Mon, 19 Mar 01 17:13:01 EST
Contents:
Re: How to eliminate redondancy? (SCOTT19U.ZIP_GUY)
Re: Bacon's cryptography? (Mok-Kong Shen)
Re: Cipher Idea #1 Block Cipher 512-bit block, arbitrary keysize (long) ("Joseph
Ashwood")
Re: Is SHA-1 Broken? (Jim Steuert)
Re: RSA encryption on Windows -- C++ source code ([EMAIL PROTECTED])
Re: Password Generator Idea ("Ryan M. McConahy")
Re: [OT] Why Nazis are evil (John Savard)
Re: Are prime numbers illegal ? (John Savard)
Crypto in VB3 ("Ryan M. McConahy")
Re: Newbie encryption ("Joseph Ashwood")
Re: Password Generator Idea ("Tom St Denis")
Re: AES encryption speed vs decryption speed ("Brian Gladman")
Re: Defenses Against Compromising Emanations of the Private Key ("Lyalc")
Re: Simple XOR "pseudo encryption" : Question about my test (Gregory G Rose)
Re: An extremely difficult (possibly original) cryptogram ("Douglas A. Gwyn")
Re: Is SHA-1 Broken? (Jim Steuert)
Re: My cypher system ("bookburn")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: How to eliminate redondancy?
Date: 19 Mar 2001 20:24:19 GMT
[EMAIL PROTECTED] (Douglas A. Gwyn) wrote in
<[EMAIL PROTECTED]>:
>Benjamin Goldberg wrote:
>> If a transformation is simultaneously one to one and onto,
>> then it is a bijection.
>
>What confuses things here is that D.Scott's notion of bijection
>forces an essentially infinite domain; it's not just N-bit onto
>N-bit but N-bit onto M-bit. And by the pigeonhole principle,
>if M < N for some inputs (fixed N) then M > N for other inputs.
>While it is possible that a compression transformation might
>generate (by iteration over all inputs) a proper subset of the
>infinite universe, it seems more likely that it would span the
>entire universe.
>
yes so whats the problem.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
http://members.xoom.com/ecil/index.htm
Scott LATEST UPDATED source for scott*u.zip
http://radiusnet.net/crypto/ then look for
sub directory scott after pressing CRYPTO
Scott famous Compression Page
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Bacon's cryptography?
Date: Mon, 19 Mar 2001 21:21:03 +0100
Frank Gerlach wrote:
>
> A comprehensive history of cryptology would definitely be interesting.
> The dominance of UKUSA in crypto definitely deserves some analysis. Why
> were they so much better than the rest of the world ?
That would be a very hard job for a historian, since
the secret angencies wouldn't cooperate in supplying the
needed materials. Churchill had certainly a well-founded
motivation, when he dissolved Blechley Park, I guess.
M. K. Shen
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Cipher Idea #1 Block Cipher 512-bit block, arbitrary keysize (long)
Date: Mon, 19 Mar 2001 12:02:06 -0800
"Benjamin Goldberg" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Joseph Ashwood wrote:
> [snip]
> > > Space requirements:
> > > be doable at about the 10k transistor level, which would make it one
> > > of the
> >
> > Is incorrect, I believe that outside of the space needed for the RAM
> > for the sboxes, it can be done in 10k transistors, the RAM for the
> > Sboxes will take ~24k additional. This will still make it smaller than
> > many of the smaller block ciphers done in parellel hardware.
>
> I think that many of the block ciphers which can gain an advantage by
> being done in parallel hardware don't necessarily use more memory than
> your cipher. Consider my cipher hypercrypt, or my more recent, unnamed
> cipher (posted Wed, 07 Mar 2001). These can be done in parallel, and
> would take very little memory, due to their simplicity.
Since there seems to be some misunderstanding I will attempt to clarify
myself. What I meant to say was that the block cipher I posted which takes
some 35000 transistors (estimated, may vary widely), will be smaller than
having 4 Rijndael (or comparable cipher) being done in parellel. Each
Rijndael block would be operated on by 10K+ transistors, 4 in parellel would
be 40K transistors, which is more than I estimate mine to take. The problem
with ciphers that use RAM is that they generally do not gain much in
complexity, or they use very sizable amounts of RAM. Mine uses 512 bytes,
which is substantial for a hardware encryption algorithm (although it will
fit easily in 1/1024 of even the smallest microprocessor cache). Mine gains
a substantial amount on complexity, requiring only addition and
exclusive-OR. Each of these has a rather minimal transistor overhead in
hardware (typically much higher cost in hardware). Thank you for your
comments. I was going to take a closer look at your ciphers, but I'm having
a bit of trouble locating the algorithms (my news server is substantially
flaky) could you either send me the descriptions or a link in private
e-mail?
Joe
------------------------------
From: Jim Steuert <[EMAIL PROTECTED]>
Subject: Re: Is SHA-1 Broken?
Date: Mon, 19 Mar 2001 15:59:15 -0500
No, you didn't mss anything. I did I jumped to conclusions. In fact in
my previous
post of last Friday asking about Design Principles of Cryptographic Hash
Functions,
I emphasized the invertibility issue, and that these hash functions
(MD4,MD5,SHA1)
are really invertible Feistel networks, for the purpose of being balanced
(and which,
I pointed out, is not in any books that I know of).
In fact, on more careful reading of this thesis, I realize that the
author of the
thesis has re-discovered the basic design principle of this type of hash
function, that it is invertible. He re-discovered it the hard way, using
BDDs. The constructive thing was his
recommendations for strenghtening the hash functions by manipulating the
input.
Assuming that he really found those values using BDD,
(and not simply the principle of inverting the algorithm), then
I would think that the same technology of BDDs would allow us to take the
SHA-1 initial chaining vector: abcde = {0x67452301,0xefcdab89,...}
and an output 160 bits abcde', and allow us to invert it to find some
symbolic relationships among the 512 message input bits.
That is, to find symbolic relationships among the
input message bits, based on the 160 hash output digest bit values.
I know of applications with just 20-byte (160-bit)
messages, with the rest set to constants, so, with this BDD technology,
SHA-1 could in theory be completely inverted symbolically
for a lot of applications, without the 2^160 complexity.
Well, it was my mistake in assuming that the BDD's actually contributed
to the point of the thesis.
Thanks for pointing that out.
David Wagner wrote:
> There seems to be no need to use BDD's to compute the fixed point.
> You can just run the compression function in reverse: If you know the
> message block, all the rounds are easily invertible (just like in a
> block cipher). And isn't this a known property of SHA-like hashes?
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: RSA encryption on Windows -- C++ source code
Reply-To: *
Date: Mon, 19 Mar 2001 20:44:46 GMT
On 11 Mar 2001 18:56:48 GMT, [EMAIL PROTECTED] wrote:
>So, what I've been trying to find is some C++ source code that fits the
>following criteria:
>- small: maybe < 20K, otherwise I'd love to use Wei Dai's Crypto++,
>- working on > Windows 98
>- free or very cheap
>- legal internationally or modifiable to handle export regulations
Just a toy:
http://belymt.jyu.fi/rp/crypt/rsa/
------------------------------
From: "Ryan M. McConahy" <[EMAIL PROTECTED]>
Subject: Re: Password Generator Idea
Date: Mon, 19 Mar 2001 15:50:40 -0500
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
Tom St Denis wrote in message
<4iQs6.64160$[EMAIL PROTECTED]>...
>
>"Moe Harley" <[EMAIL PROTECTED]> wrote in message
>news:[EMAIL PROTECTED]...
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>
>Don't sign posts.
Sign posts.
>> If this is not an original idea or it has been posted before
>> then please forgive me.
>
>Um nothing new.
>
>> I am looking for some input on this idea for a random
>> password generator. Its based on a pseudo random
>> number generator.
>
>A secure PRNG I hope... something like a LFSR, LFG or LCG are not
>strictly the best things to use.
>
>> If I generate several hundred random passwords, then
>> xor them all together to create one password, is that
>> password harder or easier to guess than the previous
>> passwords?
>
>Thats the same as using a LFSR and xoring bits together to make a
>super bit. Similar to hardware devices and xoring bits. Used to
>remove biases. You can use a Von Neuman rejector for that too. And
>no if your PRNG is any good xoring 500 bits to form a single super
>bit is not likely.
>
>> I was thinking that I could take the number of
>> milliseconds between mouseclicks MOD 1000 to
>> come up with the number of passwords to generate.
>> (which of course would limit it to an application with
>> a gui, i'd have to get random data somewhere
>> else if I ran this program from a command line)
>
>Note that using diff clock based inputs (the mouse has it's own
>clock, the UART has a clock, the cpu has a clock, the pci bus has a
>clock, etc) is only effective if there is clock drift between them
>(like flipping a bit waiting for a msec to pass, this relies on the
>clock drift from the cpu's clock and the computers PIC).
>
>Tom
>
=====BEGIN PGP SIGNATURE=====
Version: 6.5.8ckt http://www.ipgpp.com/
Comment: KeyID: 0xA167F326A5BE3536
Comment: Fingerprint: 838C 815E 5147 2168 5A76 16F1 A167 F326 A5BE 3536
iQA/AwUBOrZxH6Fn8yalvjU2EQL32QCfZJYB2TUvDnLlXbrEnnLosH+EfxUAoPqJ
IQZGWYsMUh/i7Vdy7pDA43b2
=6rUs
=====END PGP SIGNATURE=====
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: [OT] Why Nazis are evil
Date: Mon, 19 Mar 2001 20:43:02 GMT
On Mon, 19 Mar 2001 10:15:19 GMT, Benjamin Goldberg
<[EMAIL PROTECTED]> wrote, in part:
>Paul Schlyter wrote:
>> In article <[EMAIL PROTECTED]>,
>> Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
>> > The problem with bringing up Nazis, is that *they* didn't believe
>> > that what they did was unethical or immoral. In fact, if you were
>> > to accept one single premise -- that anyone who isn't a male aryan
>> > isn't a person -- you would consider everything they did to be
>> > perfectly reasonable.
The reason *why* the Nazis were evil is that they knew perfectly well
that this premise was false, and therefore they remained fully
responsible for their actions.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Are prime numbers illegal ?
Date: Mon, 19 Mar 2001 20:45:36 GMT
On Mon, 19 Mar 2001 03:59:05 -0600, Bob C. <[EMAIL PROTECTED]>
wrote, in part:
>So what has this all to do with prime numbers? At first glance:
>nothing. But everything stored on a computer, including poems,
>pictures, spreadsheets and programs, are stored as a sequence of
>binary bits--so they are simply numbers. Phil Carmody decided to make
>a version of DeCSS which was a prime number.
Note that it is also possible to make, say, a version of the
bootlegged digital version of "The Phantom Menace" that appeared on
the Web over a year ago that is a prime number.
If you can't copyright items that are on the real number line, if you
can't copyright integers, how can you copyright anything, since
everything can be coded as a number?
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: "Ryan M. McConahy" <[EMAIL PROTECTED]>
Subject: Crypto in VB3
Date: Mon, 19 Mar 2001 15:56:10 -0500
=====BEGIN PGP SIGNED MESSAGE=====
To: sci.crypt
Subject: Crypto in VB3
Does anyone know of any libraries/DLLs/source code that I could use
in Visual Basic 3?
Thanks in advance.
Ryan M. McConahy
=====BEGIN PGP SIGNATURE=====
iQA/AwUBOrZyMqFn8yalvjU2EQLmbgCfQjFk8V8ezHINCRlShQQCofcWFpwAmwQZ
2B/fTUpE3E7T6isFRQmGNo31
=1vLJ
=====END PGP SIGNATURE=====
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Newbie encryption
Date: Mon, 19 Mar 2001 12:41:45 -0800
"nex" <[EMAIL PROTECTED]> wrote in message
news:9919eh$8es$[EMAIL PROTECTED]...
> W[h]at does it means if the encryption is 128 bit, or 64 bit encryption ?
There are two different meanings. There is the meaning that is used when you
are discussing anything except the results of cryptanalysis, that is the
length of the key used, for example DES is 56-bit crypto, IDEA 128-bit,
Rjindael 128/192/256-bit, etc. Then there is the value that is the result of
cryptanalysis, these will in general be lower, these are commonly qualified
with an attack methodology, one example is DES has 48-bits of strength
against Linear Cryptanalysis.
> If i write my own encryption algorithm, how do i determin how many bit is
> it?
Because of your lack of experience with cryptanalysis you would be at first
limited to simply stating it as the key size. Later as you gain more
experience attacking ciphers you can give accurate strength measurements. I
will warn you that at first you are likely to have the algorithm you thought
was perfect in every way, reduced to just so much dust. Don't worry, it's
happened to all of us. In fact my first cipher post here it took about an
hour before someone reduced it from enormous spaces to I think the result
was I wouldn't even consider it to be dust.
> What's the highest number of bit an encryption can go up to??
Well we regularly see claims of megabit, gigabit, etc, etc. People that
actually do cryptography for a living have built certain guidelines that
they tend towards, except in certain circumstances the general concensus is
that 80-bit cryptography is barely acceptable, 100-bit cryptography is very
good, and we tend toward 128-bit cryptography be cause it is a power of 2.
> In the case of hybris .. how are antivirus experts able to determin how
many
> bit of encryption it's using? Or even what type of encrytion it's using??
Is
> it possible to crack the hybrid encryption and from there create a plu-in
to
> auto clean hybris ?
They probably just looked at an active virus wrote-down what it did and
estimated. Honestly I don't know what encryption was used in that particular
virus so I don't know. However if it takes less than 2^40 work the PC in
front of you could do it in a weekend.
If you are interested in reading up on cryptography and cryptanalysis, I'd
suggest grabbing large portions of the counterpane library
(http://www.counterpane/com/biblio ) and reading.
Joe
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Password Generator Idea
Date: Mon, 19 Mar 2001 21:11:13 GMT
"Ryan M. McConahy" <[EMAIL PROTECTED]> wrote in message
news:3ab670a1$0$62151$[EMAIL PROTECTED]...
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> >Don't sign posts.
> Sign posts.
>
> -----BEGIN PGP SIGNATURE-----
> Version: 6.5.8ckt http://www.ipgpp.com/
> Comment: KeyID: 0xA167F326A5BE3536
> Comment: Fingerprint: 838C 815E 5147 2168 5A76 16F1 A167 F326 A5BE 3536
These two comment fields are useless because if I grab the wrong key I will
know right away... i.e the sig will not be valid.
So there!!!
Tom
------------------------------
From: "Brian Gladman" <[EMAIL PROTECTED]>
Subject: Re: AES encryption speed vs decryption speed
Date: Mon, 19 Mar 2001 21:16:53 -0000
"Thierry Falissard" <[EMAIL PROTECTED]> wrote in message
news:995g2b$gpp$[EMAIL PROTECTED]...
> Unless I am badly mistaken, I have the impression
> that decryption with AES must be somewhat slower
> than encryption. Computations in the InvMixColumns
> transformation should take more time than in MixColumns,
> because of the matrix that is used for multiplication.
> Could somebody confirm this ?
For high speed implementations the encryption and decryption operations are
about the same in speed terms but key setup for decryption takes a lot
longer than for encryption.
Obviously the impact this will have will depend on whether the decryption
mode of the algorithm is needed and, if it is, how often the keys are
changed relative to the number of blocks being processed.
Brian Gladman
------------------------------
From: "Lyalc" <[EMAIL PROTECTED]>
Subject: Re: Defenses Against Compromising Emanations of the Private Key
Date: Tue, 20 Mar 2001 08:11:21 +1100
Averaging out noise has a finite limit in it's usefulness. The signals of
interest are transient, thus they to will be averaged when the occur.
A regular, or steady state signal has a S/N improvement when averaged - the
noise average increased by around 3db, the regular features of the signal
increase by around 6 db.
IMHO, unless there is a credible way of knowing when a key operatiion is
going to happen, we end up with averaged noise and averaged signals of
interest.
>> Using multiple temporary certificates is no real answer, if this threat
is
>> real. It merely moves the attack to the intermediate or root CA keys, not
>> the server keys.
>
>aha, you are saying the CA is signing hundreds of certificates per second ?
You
>have a point, but it can (and is coincidentially) adressed by using the
root key
>very seldomly.
Yes, the CA must be operating hundreds of times if the certificates are
temporary. Which CA - the Root, or an Internemdiate CA, or a local version
on the server.
[snip]
>> Hint - look at the thermal noise floor for the bandwidth and temperature
you
>> are using for the source and receiving equipment. Basically, no signal
>> under that power amplitude can be recovered, from memory.
>
>And that is why OTDRs (Optical Time Domain Reflectormeters) cannot look
below
>the noise floor when detecting cracks in fiber cables ?? Actually they do.
They
>greatly improve performance by shooting laser flashes into the fiber
millions of
>times and averaging the response. I do not see why this is impossible with
other
>repeating signals. They are btw. not doing simple averaging, but
sophisticated
>correlation and pulse encoding.
See the above point on regular vs transient averaging. OTDRs have a regular
signal to work with. Spread sprectrum, CDMA etc has predictable, specially
crafted characteristics which are exploited to advantage. It beggars
belief that a hardare crypto card also has such transmission
characteristics, since I can't see they'd be part of the functional spec.
e.g. a start signal, a stop signal, and a timing signal.
>What we simply do not know is the noise floor of the receiving antenna. A
lot
>can be done by a superconducting first amplification stage, which clearly
>produces most noise.
The thermal noise floor overrides any amplification process.
>The often heard argument that the noise generated by nearby equipment will
>contribute to security is also overstated. Look at CRTs: Assume you
directional
>antenna receives 100 monitors. That is just an reduction of SNR of 20dB
>(assuming equal power levels). Also, I would argue that the tapes
containing the
>emanations of those 100 monitors allow you to tune into every single
screen,
>because every oscillator will have a slightly different frequency ! Of
course,
>you will have to find a way of tracking oscillator frequency drift..
And there is 100 CPU, 200 power supplies (CPU and Monitor), disk drives,
et al all adding to the noise problem
There is a big difference between the eyeball being able to make sense of a
partial, less than optimum image, and getting exact binary data for a
several hundred bit long string.
As an aid to brute force, recovering a partial match may be feasible and
useful, if it could be done reliably.
Lyal
>
>
------------------------------
From: [EMAIL PROTECTED] (Gregory G Rose)
Subject: Re: Simple XOR "pseudo encryption" : Question about my test
Date: 19 Mar 2001 13:21:24 -0800
This is terrible.
In article <pfut6.1235$[EMAIL PROTECTED]>,
Fred <[EMAIL PROTECTED]> wrote:
>But in my program exemple, I dont do this. I do it by bytes.
>I XOR all of my PlaintText bytes by all of the Encryption Key Bytes, Like
>this :
>
>PlaintText : " this is my plaintext "
>Encryption Key : " encryptkey "
>
>will give us : " dxyc0yc0}i0`|qy~duhd0 "
>
>how I do it? Simple :
>
>(XOR(XOR(XOR(XOR (XOR t,e),n),c),r),y) ==> etc,
But the XOR operation is commutative and
associative. so, using the '^' symbol to mean XOR,
you compute
(((((p ^ k1) ^ k2) ^ k3) ^ k4) ^ k5) ...
== p ^ (k1 ^ k2 ^ k3 ^ k4 ^ k5 ...)
but (k1 ^ k2 ^ ...) is a single-byte key dependent
constant!
This is simply a monoalphabetic substitution
cipher, and is extremely weak. Even weaker than it
would have been if you didn't XOR the whole key
into each byte, but just the corresponding single
byte from the key string.
Urk.
Greg.
--
Greg Rose INTERNET: [EMAIL PROTECTED]
Qualcomm Australia VOICE: +61-2-9817 4188 FAX: +61-2-9817 5199
Level 3, 230 Victoria Road, http://people.qualcomm.com/ggr/
Gladesville NSW 2111 232B EC8F 44C6 C853 D68F E107 E6BF CD2F 1081 A37C
------------------------------
Crossposted-To: rec.puzzles
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: An extremely difficult (possibly original) cryptogram
Date: Mon, 19 Mar 2001 20:37:50 GMT
daniel mcgrath wrote:
> So have you figured out the system? (I think Douglas has it.)
Actually I got close enough to convince myself that the
rest wouldn't be too hard, then turned to other more
pressing matters.
------------------------------
From: Jim Steuert <[EMAIL PROTECTED]>
Subject: Re: Is SHA-1 Broken?
Date: Mon, 19 Mar 2001 17:19:39 -0500
No, you didn't miss anything. I did. I jumped to conclusions.
In fact, on more careful reading of this thesis, I realize that the author of the
thesis has re-discovered the basic design principle of this type of hash
function, that it is invertible. He re-discovered it the hard way, using
BDDs. As I put in my post of last Friday asking about hash design principles,
the hashes are really invertible Feistel steps for the purpose of
balance. As you pointed out, their was no need to use BDDs
to invert the hash, given one input (the incoming digest) fixed.
Assuming that he really found those values using BDD,
(and he did state that it "took a few minutes on a
300Mhz Pentium II computer, and required less than 128MB of RAM"
in order ...".) I infer from this that he was in fact using the inversion
generated by the Ever tool, and not simply reversing the hash algorithm.
(which certainly wouldn't take 128M of ram, or a few seconds).
I would think that the same technology of BDDs would allow us to take the
SHA-1 initial chaining vector: abcde = {0x67452301,0xefcdab89,...}
and an output 160 bits abcde', and allow us to invert it to find some
symbolic relationships among the 512 message input bits.
I know of applications with just 20-byte (160-bit)
messages, with the rest set to constants, so, with this BDD technology,
SHA-1 could in theory be completely inverted symbolically
for a lot of applications, without the 2^160 complexity.
I am still concerned that the BDD technology could invert the
160-bit output, given a smaller input. In one sense, without
s-boxes, these hash functions are simpler to model than
real ciphers. (I guess they use an array of half-adders with
carries to model addition, etc)
Do you know of any research using BDD's to invert cipher or
hash functions? I am off to learning more about BDDs.
Thanks for pointing out the flaw in my alarmist posting.
David Wagner wrote:
> Jim Steuert wrote:
> >Is SHA-1 Broken? In a recent thesis by Richard Drews Dean, he supplies
> >initial values for SHA-1's A,B,C,D,and E for which the input block "abc"
> >(in ascii, padded and Merkle-Damgard strenghtened), is a fixed point.
>
> Isn't this the case for all chaining-based hash functions (MD5,SHA,...)?
> The chaining-based hashes have a compression function E_k(x) which takes
> a chaining variable x and a message block k and mixes them together; then
> the new chaining variable becomes x + E_k(x). Note that E_k(.) is invariably
> a bijective function, whose inverse is easy to compute given k (essentially,
> you can think of E_.(.) as a block cipher, and the inverse is the decryption
> function). Thus, we may readily compute x such that E_k(x) = 0; then x is
> a fixed point of the hash.
>
> This doesn't seem like a terribly important concern to me. So long as
> it is infeasible to choose a message prefix that brings the chaining variable
> to this fixed point (i.e., if it is secure against inversion attacks), there
> seems to be little way to exploit this property of the compression function.
> Did I overlook something?
------------------------------
From: "bookburn" <[EMAIL PROTECTED]>
Subject: Re: My cypher system
Date: Mon, 19 Mar 2001 12:53:17 -0800
"Mok-Kong Shen" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>
>
> bookburn wrote:
> >
> > This is a "what if" by a mere bumbler who looked at an
encyclopedia
> > article, so I expect to be shot down.
> >
> > My cipher system is basically a simple three-layered process
using: 1)
> > clear text; 2) use of a published text, like a page of a daily
> > newspaper, which is chosen by a formula based on something
variable
> > like time and temperature of alternating cities on certain days,
with
> > identification of letters of the alphabet by numbered spaces in
the
> > text; 3) random use of the numbered spaces identifying letters of
the
> > alphabet, blank spaces, and punctuation, producing a long list of
> > single numbers in bytes (spaces before and after set off numbers)
; 4)
> > use of a mask to select only words in the clear text that are the
> > message; 5) in addition, a key list of coded terms could be used
to
> > refer to some things.
> >
> > I'm basically thinking my system could be set up with computer
> > programs at each end so that the long list of numbers can be
instantly
> > converted with the use of the same key text.
> >
> > Is this a workable cipher system? How could you ever break it?
> > bookburn
>
> Point (2) of using some contrived (uncommon, hence difficult
> to guess) scheme to identify a piece of publically available
> text for the purpose of deriving a shared secret is known.
> How secure that is, is difficult to say in my view. (I would
> vaguely say 'it depends'.) Points (3-5) are unclear to me.
> Perhaps you could provide a tiny example to illustrate your
> scheme.
Sorry if my parameters are unclear. I wanted to describe three phases:
substitution, masking, and encoding with key terms. But the
substitution part is really the guts of it.
I assume transmission between two computers, A-B, using the Internet.
Clear text of message is composed, then a text from some common
source is used by A for substitution, such as a page of a periodical
available on the internet. Every space location on the page is
numbered by computer, resulting in numbers for all the alphabet, blank
spaces, and punctuation marks. The computer program then randomly
selects numbers on the page that go with the letters in the message,
resulting in a long list of single digits in binary code. This long
list of numbers then is sent by e-mail to B, who uses the same
computer program and common source text to translate the random
numbers on the page back to alphabet. Spaces between words are just
numbers indicating emplty spaces on the text page.
That's basically it, just substituting numbers representing location
on a page for the letters on that page, except that more program
filters could be added to permute the numbers, null words could be
woven into the product and be filtered out, etc. I assume that the
weak point would be in identifying the text source of the
substitution, but it seems like it would take a lot of mainframe
computers and data bases including all the possible sources to do it.
bookburn.
>
> I my humble view answering questions like your last one is
> in general difficult. For breaking a given cipher (that
> is susceptible to be broken by the current state of
> knowledge) may often require much thoughts/intuitions and
> experimentations/work/time. Thus it is always easy to put
> up a challenge but hard to take it up. If nobody answers
> that question of yours, it doesn't follow at all that your
> cipher is strong. An analogy: In mathematics it is easy to
> put up problems that are hard to get worked out. Some may
> need much work to be solved, others may be not solvable
> but the non-solvability is rather difficult to prove (e.g.
> the trisection of an angle). But this is all opionions of
> a humble non-expert like me. I don't exclude that some
> experts would at once give a very easy break of your scheme
> or prove the opposite.
>
> M. K. Shen
> ---------------------------
> http://home.t-online.de/home/mok-kong.shen
------------------------------
** 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 by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
