Cryptography-Digest Digest #58, Volume #10 Mon, 16 Aug 99 15:13:03 EDT
Contents:
rsa in other fields (Tom St Denis)
Blowfish algorithm - Is it full proof? (Pradeep Rathi)
Re: Statistical occurrence of letters in english (Paul Koning)
Re: CBC, IV's, and Blowfish (Paul Koning)
Re: Triple DES (168bit) -- Triple DES (112bit) (Paul Koning)
Re: compress then encrypt? (John Savard)
Re: NIST AES FInalists are.... (Lee Winter)
Re: Blowfish algorithm - Is it full proof? (Ray Marron)
Re: rsa in other fields (Medical Electronics Lab)
Re: rsa in other fields (Bob Silverman)
Re: Triple DES (168bit) -- Triple DES (112bit) ("karl malbrain")
Re: Smart card generating RSA keys (Peter Gutmann)
Re: Modified Vigenere cipher (JTong1995)
Re: Cracking the Scott cryptosystems? ([EMAIL PROTECTED])
Re: New encryption algorithm (SCOTT19U.ZIP_GUY)
Re: NIST AES FInalists are.... ([EMAIL PROTECTED])
Re: Something For Cryptanalysts to Do (John Savard)
Re: CRYPTO DESIGN MY VIEW (Mok-Kong Shen)
----------------------------------------------------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: rsa in other fields
Date: Mon, 16 Aug 1999 14:45:46 GMT
RSA is done in the field of whole numbers less then pq.
Is it possible to use RSA in other fields (say elliptic curve ?) would
it be stronger (more resistant to solving)?
another question: What is the matrix step really (when solving RSA)
and how much memory is require for a n-bit modulus?
(excuse the ignorance...)
Tom
--
PGP 6.5.1 Key
http://mypage.goplay.com/tomstdenis/key.pgp
PGP 2.6.2 Key
http://mypage.goplay.com/tomstdenis/key_rsa.pgp
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Pradeep Rathi <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.clipper,comp.security.misc
Subject: Blowfish algorithm - Is it full proof?
Date: Mon, 16 Aug 1999 10:40:17 -0500
Hi!
I'm using the blowfish algorithm, written in perl, to encrypt a NUMERIC
INTEGER VALUE. My concern is if I mess around with the encrypted
information and then try to decrypt it, is there a possibility of another
numeric value being returned. To illustarte,
1. Encrypt 12345 and let's call the encrypted information 'A'.
2. Manipulate 'A' and let's call that 'B'.
3. Decrypt 'B'.
4. Is there a possibility of 67890 being returned.
An assumpiton: I know nothing about the KEY that was used to encrypt or
decrypt the information. All I've is two functions encrypt() & decrypt()
that I can use.
I would appreciate any comments.
Thanks,
Pradeep
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: Statistical occurrence of letters in english
Date: Mon, 16 Aug 1999 11:26:59 -0400
[EMAIL PROTECTED] wrote:
> ...
> Most languages has biases (structures) that can be exploited.
All languages, not "most" languages. The details will vary all
over the map. Consider letter pairs: in Japanese, consonant/vowel
pairs are the basic building block, which is in fact reflected in
the writing system (Kana). Some other languages like to pile
up long strings of consonants.
paul
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: CBC, IV's, and Blowfish
Date: Mon, 16 Aug 1999 11:32:38 -0400
[EMAIL PROTECTED] wrote:
>
> <snip>
> The IVs do not have to be secret, but they should be unique (starting
> IV) to each message. They are essentially 'salt' values.
>
> The reason why they don't have to be secret is (from AC) consider
> encrypting your second block... The IV is just C[0].
>
> I would use
>
> IV = time_since_1990_in_msec
Actually, there are some arguments that you should not use
an upcounting value like that as the IV (because then several
consecutive messages will have IVs that differ only slightly).
A real world IV example: IPSec ESP uses "explicit IV" for the
IP encryption; that is, the IV is carried in the header, in
the clear. There's a recommendation that the first packet
for any particular security association should use a random
number for the IV, and subsequent packets can use the last
cipherblock of the preceding packet as the IV.
paul
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: Triple DES (168bit) -- Triple DES (112bit)
Date: Mon, 16 Aug 1999 11:22:51 -0400
Frank Piepiorra wrote:
>
> Several publications refer to Triple DES with the key size 168 bit or 112
> bit. Both seems to have Triple DES but what in detail, besides the key
> length :-) is the difference and does it have an impact on security?
One difference that may matter: some protocols, such as IPSec,
support the 168 bit version of 3DES but not the other one.
I think the reason is that it certainly can't hurt, may help,
and the key exchange protocol (IKE) provides enough bits that
there isn't a reason to go for 112 rather than 168.
paul
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: compress then encrypt?
Date: Mon, 16 Aug 1999 15:27:25 GMT
Tom St Denis <[EMAIL PROTECTED]> wrote, in part:
>Ok other then
>1. Making the message smaller
>2. Making the plaintext harder to guess (but not impossible with
>several adjacent blocks).
>What are the clear benefits of compression before encryption?
There are no other benefits. Although "Making the plaintext harder to
guess" doesn't quite fully express how compression is beneficial in
reducing reduncancy.
John Savard ( teneerf<- )
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
Date: Mon, 16 Aug 1999 12:27:46 -0400
From: Lee Winter <[EMAIL PROTECTED]>
Subject: Re: NIST AES FInalists are....
[EMAIL PROTECTED] wrote:
> In article <7p40k1$i9i$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
> > No I wont talk about back doors. But if you read some of
> > the comments in books such as the Puzzle Palace you
> > may believe as I that DES was crackable by the NSA in
> > a small amount of time when it came out. However it was
> > more likely crackable by a fast search. They had the abitlity
> > to do it then with specialized hardware. I don't think they can
> > do blind search fast enough to cover the full key lengths used
> > into todays methods. But witha an intelligent searchig program
> > they may easily be in reach of a combination searching and
> > analyzing. I am sure they most have a host of programs to
> > analyze the hell of out the methods in use.
>
> Well as for brute force if the keyspace is flat the fastest method is
> parallel linear searches. No matter what algorithm you use it will not
> be faster then testing all keys sequentially (unless the keyspace is
> not flat).
>
> If for example you have a 100 byte RC5 encrypted message the fastest
> method would be to search the key (the best iterative attacks requires
> much more plaintext/ciphertext pairs).
>
> In these 'weak' methods with 80+ bit keys brute force is not very
> feasible, thus making the actual cipher secure (now a question towards
> the system).
>
> BTW I seriously doubt in the 70's they had the ability to search the
> DES keyspace in less then a year.
There are two federal institutions that use peculiar units of measure for
computers. While most of us use FLOPS, MIPS, MIPS-years, Los Alamos
National Laboratories and the National Security Agency use the unit
'acres'.
The only sensible estimate of the computing power of these institutions is
"more than that". This is not a recent development.
------------------------------
From: Ray Marron <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.clipper,comp.security.misc
Subject: Re: Blowfish algorithm - Is it full proof?
Date: Mon, 16 Aug 1999 17:23:14 GMT
In article <Pine.GSO.4.10.9908161020390.5975-
[EMAIL PROTECTED]>,
Pradeep Rathi <[EMAIL PROTECTED]> wrote:
> Hi!
>
> I'm using the blowfish algorithm, written in perl, to encrypt a
NUMERIC
> INTEGER VALUE. My concern is if I mess around with the encrypted
> information and then try to decrypt it, is there a possibility of
another
> numeric value being returned. To illustarte,
>
> 1. Encrypt 12345 and let's call the encrypted information 'A'.
> 2. Manipulate 'A' and let's call that 'B'.
> 3. Decrypt 'B'.
> 4. Is there a possibility of 67890 being returned.
>
> An assumpiton: I know nothing about the KEY that was used to encrypt
or
> decrypt the information. All I've is two functions encrypt() & decrypt
()
> that I can use.
>
> I would appreciate any comments.
>
> Thanks,
>
> Pradeep
>
>
Technically, you are not encrypting an integer, but the text
representation of the integer. If you modify the encrypted text and
then attempt to unencrypt it (regardless of the encryption key used),
you are going to get something entirely different than the original
plaintext back -- probably garbage.
No encryption algorithm is "foolproof" or perfect. Blowfish is a good
algorithm and is currently being considered as a candidate for
replacement of DES (or some variation thereof, TwoFish I think?). No
algorithm is uncrackable, but if implemented properly (the hard part)
can be very secure. Visit Bruce Schneier's (the author of Blowfish)
company website for more theory and information on Blowfish:
http://www.counterpane.com
You can even subscribe to his monthly newsletter on encryption that I
find very informative.
--
Ray Marron
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Medical Electronics Lab <[EMAIL PROTECTED]>
Subject: Re: rsa in other fields
Date: Mon, 16 Aug 1999 12:15:27 -0500
Tom St Denis wrote:
>
> RSA is done in the field of whole numbers less then pq.
>
> Is it possible to use RSA in other fields (say elliptic curve ?) would
> it be stronger (more resistant to solving)?
There's no point to it, but yes, you can pretty much do anything
with math. ECC works over GF(p), GF(p^n) and particularly GF(2^n).
You get more security with fewer bits than RSA (1024 bits of RSA is
about 160 bits of ECC). Solving RSA is sub-exponential in time,
solving ECC is fully exponential. Why would you use a weaker system
if you don't have to?
> another question: What is the matrix step really (when solving RSA)
> and how much memory is require for a n-bit modulus?
A ton of mathematical detail. If you check the RSA web site there
might be an answer in their FAQ.
Patience, persistence, truth,
Dr. mike
------------------------------
From: Bob Silverman <[EMAIL PROTECTED]>
Subject: Re: rsa in other fields
Date: Mon, 16 Aug 1999 17:07:39 GMT
In article <7p986n$5v9$[EMAIL PROTECTED]>,
Tom St Denis <[EMAIL PROTECTED]> wrote:
> RSA is done in the field of whole numbers less then pq.
No. RSA is performed in (a) cyclic subgroup of a finite ring.
>
> Is it possible to use RSA in other fields (say elliptic curve ?) would
> it be stronger (more resistant to solving)?
You seem to have some faulty assumptions.
An elliptic curve (whether taken over a field of
characteristic 0 or characteristic p) does not form a FIELD. Over
Q it forms a (perhaps infinite) finitely generated Abelian group.
Over Z/pZ it forms a group that is either cyclic or bi-cyclic.
All of today's public key algorithms operate in some cyclic group.
If one could indeed embed an elliptic curve encryption algorithm in
a field, it would be a lot easier to break. It would reduce to
solving an ordinary discrete log problem for which we have index
calculus attacks.
Could you clarify as to what you are really looking for?
>
> another question: What is the matrix step really (when solving RSA)
One collects a set of relations of the form product p_i^a_i = phi
(product q_i^b_i) where phi is some map taken modulo the number being
factored. You desire to find a subset whose product is a square. This
is done by reducing the exponents in each relation mod 2 and forming
a vector of 0's and 1's. Finding a set whose product is a square
is equivalent to finding all of the a_i and b_i to be EVEN. This
corresponds to finding a set of vectors that sum to 0 mod 2, and
this is a set of equations to be solved.
The size of the matrix (in practice) can not be given by a simple
function of n because it depends on many parametric choices one makes
when sieving. There are a lot of space/time trade-offs that can be
made. Further, you need to consider not just the size of the matrix,
but also its density. RSA-140 required about 800 Mbytes to store the
matrix. A 512-bit number will require 4 to 5 times that much.
--
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/
Share what you know. Learn what you don't.
------------------------------
Reply-To: "karl malbrain" <[EMAIL PROTECTED]>
From: "karl malbrain" <[EMAIL PROTECTED]>
Subject: Re: Triple DES (168bit) -- Triple DES (112bit)
Date: Mon, 16 Aug 1999 10:54:46 -0700
fungus <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> In article <lkit3.81$[EMAIL PROTECTED]>,
> "karl malbrain" <[EMAIL PROTECTED]> wrote:
> > The key size never materially exceeds 64 bits with a 64 bit block
> > cipher. Triple DES materially extends the original 56 bit key size
> > to 64 bits. Karl
> >
>
> Not true.
>
> Think of DES as a function of the key combined with the message.
>
>
> You may be able to find a 64-bit key which decodes the first block
> of a message, but the same key won't decode the rest of it.
So, even if you just repeat once again, how much loss are you able to
tolerate? It's not the same scale as a 128 bit block cipher. Karl M
------------------------------
From: [EMAIL PROTECTED] (Peter Gutmann)
Subject: Re: Smart card generating RSA keys
Date: 16 Aug 1999 18:19:37 GMT
[EMAIL PROTECTED] (Matthias Bruestle) writes:
>Peter Gutmann ([EMAIL PROTECTED]) wrote:
>> The comment about "simply a random number" hides a lot of detail. With any
>> type of PKC (conventional or ECC), you can't generate good keys without a
>> source of unpredictable random numbers, something which is virtually
>> unobtainable in a smart card.
>I wonder why the don't let supply true random number with the key
>generation command and mix this with internal bad random numbers.
That's a method which is favoured by the NSA, you load a trusted seed value
into a device and generate keys from that. Assuming the seed value is from
a known good/trusted source (which, for users of NSA crypto, it would be),
and you can keep the value secure, it's a reasonably safe way to generate keys
since they're coming from a PRNG with known properties, as opposed to a
typically difficult-to-analyse and subject-to-external-influences source such
as the various techniques used by smart cards.
Peter.
------------------------------
From: [EMAIL PROTECTED] (JTong1995)
Subject: Re: Modified Vigenere cipher
Date: 16 Aug 1999 18:38:32 GMT
>Alexander Demin wrote:
>> But Wetherell used the non-plain alphabet and the table looks like
>> this:
>> abcdefghijklmnopqrstuvwxyz
>> -------------------------------------
>> a| qwertyuiopasdfghjklzxcvbnm <-- this is a random mixed alphabet
>> b| wertyuiopasdfghjklzxcvbnmq
>> c| ertyuiopasdfghjklzxcvbnmqw
>> ...
>> z| mqwertyuiopasdfghjklzxcvbn
This cipher uses a known sequence plaintext (in this case, a direct
standard sequence) and a series of related, mixed sequence cipher alphabets.
After determining the period, the usual attack against this type of cipher is
to use direct symetery of position with an assumed plaintext crib, such as an
assumed sterotypical begining or ending. It doesn't matter if the plain
component is a direct sequence, a reversed sequence, or a mixed sequence; as
long as the sequence is known the cipher is susceptable to a direct symetery of
position attack.
In the case of an unknown plain alphabet sequence, and a known sequence
series of ciphertext alphabets (say a period of 10 and some type of
keyword-shifted ciphertext alphabets) the approach would be to determine the
period, then using a Chi squared test (or calabrated eyeball for a large enough
message), determine the shift of the alphabets and aline them "in depth", and
then collasp the matrix of alined alaphabets into a single monoalphabetic
distribution. At that point the message is solved as a monoalphabetic simple
substitution cipher.
Jeffrey Tong [EMAIL PROTECTED]<Jeffrey Tong>
PGP 5 Key available for download at WWW.PGP.COM Key ID: BFF6BFC1
Fingerprint: 6B29 1A18 A89A CB54 90B9 BEA3 E3F0 7FFE BFF6 BFC1
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Cracking the Scott cryptosystems?
Date: Sun, 15 Aug 1999 16:05:47 GMT
In article <7p6kbd$36h6$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
> Actually the major basis to it is the safety of a large random S-
table
> and the mixing do to "wrapped PCBC" chaining along with pre and
> post whitening. Funus like most people shoot there mouth off and have
> never really looked at the source code. THe totally code is supplied
with
> the method but I guess having people read is just to much for most.
> I file that scott19u is far stronger due to 19 boudaries and 9 bit
shift.
Why? You have never prooved that your method is more resistant then
any other block cipher. You never prooved that W-PCBC is stronger then
CBC.
>
> THere is a method where you can see weaknesses in all the current
> ciphers. Fist I am assumong you use mode where the input file matches
> the output file in legnth.
> Encrypt using any of the AES or blessed candidates. Then if possible
> revese file byte order encrypt again with second key. Then change one
> bit in file. And decrypt the mess. There will be only a small area of
change
> from the original file. This is manly due to the fact the NSA wants
to only
> look at a small fragment of code to try to break a system so methods
that
> rely on this weakness are the only ones in common use. This weaknes is
> not in my code. I did a lot of testing using the DIEHARD programs in
various
> ways, It actually is a very simple solid program that works. But the
BS and
> Wagner types over and over say it is weak. Wagner even said on this
form
> his Slide Attack would finish it. Well the asshole was wrong but that
doesn't
> stop them from saying it must be weak they just haven;t figures out
how.
Are you a complete utter morron? Flipping bits in the ciphertext will
not get you bits in the plaintext. You have to learn the key or guess
it. If I give you C = Ek(P), you flip a bit and the other person
decrypts it they will know the message is invalid and delete it.
The only way Mallory (the attacker) can learn the key is to guess the
key and plaintext (unless they know a portion). It doesn't matter what
method you use.
Tom
--
PGP 6.5.1 Key
http://mypage.goplay.com/tomstdenis/key.pgp
PGP 2.6.2 Key
http://mypage.goplay.com/tomstdenis/key_rsa.pgp
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: New encryption algorithm
Date: Mon, 16 Aug 1999 18:46:11 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>On Sun, 15 Aug 1999 20:25:24 +0200, Mok-Kong Shen
><[EMAIL PROTECTED]> wrote:
>
>
>>one can apply for a patent...[snip]...
>>At this point one can discontinue
>>the patent process. This way, one pays only a fairly minimal sum of
>>money (assuming that one can formulate the application without the
>>help of patent lawers) but has one's ideas documented in an official
>>publication. As far as I know, the same can't be done in US, since
>>there is no public review of US patents.
>
>Yes, you can, and its absolutely free. The U.S. Patent Office has
>a "publication" that anyone can use to publish information that
>might be patentable, but for which the person does not want
>to pursue a patent. The reason for public disclosure of something
>like this is to ensure that no one else will later rediscover
>your idea and then patent it and prevent you from continuing
>to use it. Of course, publishing in the free Patent Office
>journal does not give you any exclusive rights to the idea.
>I don't think this "journal" has any real circulation, but
>it is used to establish legal "prior art" for an idea.
>
>
>Bob Scott
>Ann Arbor, Michigan (email: rscott (at) wwnet (dot) net )
>(My automatic return address is intentionally invalid.)
Can one post C source of encryption in it with out fear of
voilating the export laws on encryption.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: NIST AES FInalists are....
Date: Mon, 16 Aug 1999 18:41:35 GMT
Douglas A. Gwyn wrote:
> [EMAIL PROTECTED] wrote:
> > How convenient for you that the rules allow you
> > to flaunt how much you know on Usenet and to
> > belittle the skill of respected cryptologists ...
| | in
| | comparison to what you know about the NSA, but
| | don't allow you to back up what you claim with
| | any facts.
> I'm not flaunting anything,
It was sarcasm. The point is that insiders do not
post conclusions drawn from secret information. They
don't even introduce the NSA's name into public
discussions. You have the same trickle of information
as everyone else and it does not justify your
conclusion.
> just trying to be helpful
> in advancing the public state of cryptology compatibly
> with my obligation to protect legitimate national
> interests. My personal agenda is to ensure as soon as
> possible that everybody can have adequate protection
> for the privacy of their communications.
So naturally you go about it by insulting the able and
dedicated people who are working to ensure just that.
> It's not my
> fault if you think the state of the art is defined by
> academics rather than by actual practitioners.
You can only make up this position for me because
you don't say what you mean. Attacks are often
called "academic" simply because they are far more
generous to the attacker and require far more
resources than are likely to be available in an
attempt to recover intelligence from ciphertext.
If cryptanalyst-generous attacks are automatically
"academic" then of course the state of the art in
cipher design is to resist academic attacks. If not,
then I can report the AES conference I attended was
full of practitioners.
> Other
> posters have shown a better understanding of this issue.
I see you've joined Dave Scott in proclaiming the
NSA's capabilities without any justification and
setting the state of art at your own fantasy.
In another branch of the thread you wrote:
| I know of at most a dozen "outside"
| cryptomathematicians that the Agency would be
| happy to have working for them.
Literally, that's a statement of how little you
know. Nevertheless, you seemed to present it as
an argument for the advanced state of the NSA, but
for that to be valid we would also need to know
that when some cryptologic group within the NSA
would want a certain outside cryptologist, that
you would probably be informed. Do they send you
a memo or what?
--Bryan
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Something For Cryptanalysts to Do
Date: Mon, 16 Aug 1999 18:56:33 GMT
There was a thread - it seems to be gone now - asking about ways to
implement a mental challenge/response protocol for passwords.
That inspired the train of thought that led to the previous post.
However, nothing was said about the "good" part: what mental algorithm
could our diplomat use?
Let's even *try* to have something that provides security through a
key, and not through obscurity. (That is a *serious* constraint on
this sort of scheme!)
To achieve this, I've decided I need to complicate the computer
display somewhat. Now, screens like
0 YEJTLUNSWRHPFKCQDAMOXBVGIZ
1 KGYQULXIAHZOCBJSTDNFWERVPM
2 ZGUXMLHQPOBYAIFDNJETRSCVKW
3 AVNUYLPSGXORIQFCBZKWTJDHEM
4 PJGAWRUCBLZQKYNSETIDMVXFOH
5 QRTNXSKLWUGBJHEZYOFMVCAPDI
6 ISJQBPAXGTYRWOLNHCMKUFZEDV
7 ZHJMRQCNKTWLXPYEOUBDAVGIFS
8 UNYQKLVAOPFTISRJMEXCHWGBDZ
9 LRCUOWIVGTEYASFPDXBJMQNZKH
7 428 32 901 2654
312 5 4033 171 22
are to alternate with screens like
0123456789
----------
0 9498261073
1 5032717568
2 3187503914
3 4270134132
4 6915325341
5 1766098250
6 7301650687
7 8523972825
8 0649849409
9 2854486796
and our intrepid diplomat starts out by memorizing a secret number:
563. Also, he memorizes the acronym PCB, standing for
Plaintext/Cipher/Both (instead of polychlorinated biphenyl).
In the digits below the alphabets, he looks for the leftmost 3, 5, or
6 in a column. If none is found, or if both digits in the first column
with one are from that set, the screen is skipped. Also, if a blank
rather than a digit shares the column with our first digit from the
set, we skip the screen.
Here, we find a 3 with a 7 above it in the first column. The two
digits after the 3 are 12. (If the two digits after the number found
were the same, we would again skip the screen.)
Since 3 is the third digit of our secret number, "Both" applies.
Our plaintext letter is T. We bump it ahead in the alphabet (Both
includes plaintext) to U, and look for U in alphabet 1.
X is found before it - we alternate from left to right as we go
through our message, in alphabet 2. It's changed to Y, since "Both"
includes ciphertext.
Meanwhile, after the 7, the next three digits are 428.
So that becomes our new secret number (in code).
On the next screen, we put the digits 428 in at the side, and our
secret number 563 is the key, used at the top. So our new secret
number is 239. We only look for a new secret number if we had not
skipped the screen.
Maybe this is too complicated for people to do in their heads...and
much of the security is still due to obscurity.
Needless to say, the screens are generated by means of a very
sophisticated algorithm, so if our diplomat is not being bugged, the
message would be unbreakable. But if he is, the security of a scheme
like this becomes an interesting question.
John Savard ( teneerf<- )
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: CRYPTO DESIGN MY VIEW
Date: Mon, 16 Aug 1999 19:38:10 +0200
SCOTT19U.ZIP_GUY wrote:
>
> are many such methods. I have been looking most recently
> at using the BWT method and thought I was close to getting it to
> work but my requirement that every file even if the wrong file should
> be a valid compressed file so no information in sturcture could be
> used by attacker to tell if it is a valid file.
I don't see how you requirement can be realized. If you have a file
A compressed to B and the last symbol written to B consists of, say,
4 bits. If I delete the last bit of B to become C, then on
uncompressing C the software will find the last 3 bits of C that it
can't decode. So this 'wrong' file C obvioulsy will be determined
to be an invalid file. Or do I miss something?
M. K. 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 (and sci.crypt) via:
Internet: [EMAIL PROTECTED]
End of Cryptography-Digest Digest
******************************
