Cryptography-Digest Digest #59, Volume #10 Mon, 16 Aug 99 17:13:04 EDT
Contents:
KRYHA Cipher Machine Question (JTong1995)
Re: Blowfish algorithm - Is it full proof? (John Savard)
Re: Blowfish algorithm - Is it full proof? (Michael J. Fromberger)
Re: KRYHA Cipher Machine Question (John Savard)
Re: Triple DES (168bit) -- Triple DES (112bit) (John Savard)
Re: Cracking the Scott cryptosystems? ("Douglas A. Gwyn")
Re: NIST AES FInalists are.... (John Savard)
Re: NIST AES FInalists are.... ([EMAIL PROTECTED])
Re: NIST AES FInalists are.... ("Thomas J. Boschloo")
Re: NIST AES FInalists are.... (John Savard)
Re: NIST AES FInalists are.... ("Thomas J. Boschloo")
Re: compress then encrypt? ("Base2")
Re: rsa in other fields (Anton Stiglic)
Re: Wrapped PCBC mode (Jim Felling)
Re: rsa in other fields (David A Molnar)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (JTong1995)
Subject: KRYHA Cipher Machine Question
Date: 16 Aug 1999 19:18:52 GMT
I recently found a copy of Rudolph Lauer's book, Computer Simulation of
Classical Cryptographic Systems (Aegean Park Press #32). The book discusses
the KRYHA cipher machine, which used an irregular shifting of the
polyalphabetic cipher components to produce a long key, and that the sum of the
shifts in 1 cycle of the key needed to be relatively prime to the number of
letters in the alphabet for maximum security. Some questions: 1). Does anyone
know where I can find more information on the history of the KRYHA device
itself? Who used it? When was it in use? What level of security was it
designed to provide (e.g., SIGABA [high level], M-209[med level],
M-136[tactical])? 2). The description of the operation of the device is
quite limited. Is there a good source for understanding what the operating
principles of the device were? 3). What advantage is gained in having a key
such that the sum of the shifts are relatively prime to 26? 4). As to
cryptanalysis of the KRYHA system, the book mentions the use of isomorphs and
references Sacco, Candela, and Friedman. Was a general solution ever
developed? Other than the use of isomorphs, are there other known attacks?
And lastly, 5). Does anyone know a source for some known plaintext messages,
encrypted with a known key, that can be used to verify that the software
simulation is correctly implementing the algorithm by producing the correct
output [message]? Thanks in advance for your help.
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] (John Savard)
Crossposted-To: comp.lang.clipper,comp.security.misc
Subject: Re: Blowfish algorithm - Is it full proof?
Date: Mon, 16 Aug 1999 17:53:21 GMT
Pradeep Rathi <[EMAIL PROTECTED]> wrote, in part:
>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.
There is no possibility of anything but 12345 being returned when you
decrypt A.
So, Blowfish *works*.
It does not contain any inherent error checking. If you encrypt 67890,
you will get something: call it 'C'.
If you turn A into C, you will get 67890 when you decrypt.
It is possible, only unlikely, that A and C might be similar,
differing even by only a single bit.
If you want error checking or authentication or validation, you must
supply it yourself separately from Blowfish, or DES, or any other
block cipher.
Trying to build that into a block cipher would create weaknesses; one
would know that similar input strings *always* encipher to very
different output strings, and this would involve a lot of structure.
John Savard ( teneerf<- )
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: Michael J. Fromberger <[EMAIL PROTECTED]>
Subject: Re: Blowfish algorithm - Is it full proof?
Date: 16 Aug 1999 18:53:15 GMT
In <[EMAIL PROTECTED]> Pradeep Rathi
<[EMAIL PROTECTED]> writes:
>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.
Hi there,
Anything is possible, of course. Does your Perl Blowfish
implementation correctly encrypt and decrypt the test vectors from
Counterpane's Blowfish page? Here is the URL:
http://www.counterpane.com/vectors.txt
You should first verify that your implementation correctly handles the
test vectors, then worry about whether your particular data are
working as desired.
That having been said, you should probably also check CPAN for a
Blowfish module. I'm almost certain such a thing has been done
before, and integrating with a C implementation is likely to be much
faster and easier than trying to roll your own in Perl bytecode.
Cheers,
-M
--
Michael J. Fromberger Software Engineer, Thayer School of Engineering
sting <at> linguist.dartmouth.edu http://www.dartmouth.edu/~sting/
goZIBsIgJbdOL2UjUllG4XLRpJv9LHraa4CTv+Li6Q0pMUT8YsoMVXEXjLMSJOHSN6RnpwqF
Remove clothing if you wish to reply to this message via e-mail.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: KRYHA Cipher Machine Question
Date: Mon, 16 Aug 1999 19:49:33 GMT
[EMAIL PROTECTED] (JTong1995) wrote, in part:
>1). Does anyone
>know where I can find more information on the history of the KRYHA device
>itself? Who used it? When was it in use? What level of security was it
>designed to provide (e.g., SIGABA [high level], M-209[med level],
>M-136[tactical])?
It was a commercial product. The book "Machine Cryptography and Modern
Cryptanalysis", by Cipher A. Deavours and Louis Kruh gives some
information on its history. Its level of security can be described as
[snake oil].
It is sufficiently limited that I didn't even deign to put information
about it up on my web page, IIRC.
>2). The description of the operation of the device is
>quite limited. Is there a good source for understanding what the operating
>principles of the device were?
Essentially: there is a cipher disk, where one alphabet rotates
relative to another one. Each time a letter is enciphered, one pushes
a lever or button on the device, and a gear shifts the disk a certain
number of spaces. The gear has several different shifts on it, and
then, after a certain number (say 17) letters are enciphered, it
repeats the sequence of shifts.
>3). What advantage is gained in having a key
>such that the sum of the shifts are relatively prime to 26?
In this way, when the cycle of shifts repeats, the alphabets don't
also repeat, so the period is 26 times longer.
>4). As to
>cryptanalysis of the KRYHA system, the book mentions the use of isomorphs and
>references Sacco, Candela, and Friedman. Was a general solution ever
>developed? Other than the use of isomorphs, are there other known attacks?
Its cipher is similar to a progressive-key with keyword Vigenere with
mixed alphabets.
John Savard ( teneerf<- )
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Triple DES (168bit) -- Triple DES (112bit)
Date: Mon, 16 Aug 1999 18:22:52 GMT
"karl malbrain" <[EMAIL PROTECTED]> wrote, in part:
>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.
Capturing 2^64 blocks of known plaintext may not be possible, even
while performing 2^64 key trials is.
Hence, while one may speak of the theoretical complexity of an attack
as not being increased, in practice, there can be as many as (2^64)!
keys for a 64-bit block cipher, and increasing the key size up to that
limit can, under appropriate circumstances, genuinely add to the
problem facing a cryptanalyst.
John Savard ( teneerf<- )
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Cracking the Scott cryptosystems?
Date: Sun, 15 Aug 1999 16:18:20 GMT
"SCOTT19U.ZIP_GUY" wrote:
> Actually DES or any random generator show a likeness to a OTP
> if used properly and for ONE TIME since any sequence could in theroy
> have come from a OTP it is just that when the source used for the pad
> is known then analysis can say that it is not a valid source for use
> with a OTP.
I'm not sure what you meant by the last part there, but the first
part shows a profound misunderstanding -- as enterrottacher hinted,
use of DES as the encryption system imposes a tight set of
constraints that makes it quite feasible to recover even a single
message with a key used just once, with virtual certainty about
the result (witness the EFF DES cracker). That is nothing like a
OTP system. The fact that the ciphertext is a possible output
from some unrelated OTP system has nothing to do with the DES
encryption itself.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: NIST AES FInalists are....
Date: Mon, 16 Aug 1999 20:04:46 GMT
[EMAIL PROTECTED] wrote, in part:
>People who talk about knowing secret stuff don't.
That's the _general_ rule.
However, the media relations officers of secret agencies and such like
doubtless have clearances, and they sometimes admit they can't say
everything they know.
Of course, many people who don't know secret stuff don't claim to
either. I would not be able to have such a...chatty...web site as I do
about cryptography if I knew any secrets, or was even remotely
connected to any group that handled them. And it is only because I
"only know what I read in the papers" that I dare approach so close to
irresponsibility as to point out that the performance of the EFF
DES-cracker appears to hint that a brute-force 80-bit search is
possibly within, or nearly within, the grasp of the NSA. (Which says
something about SKIPJACK, but since anything else longer than DES is
at least either 112 or 128 bits, it isn't reason for panic.) Although
a very sensitive topic, to point out what is publicly known only
informs the ordinary person; potential enemies have already gotten out
their slide rules.
Even Bruce Schneier has publicly claimed to have been told one or two
things in confidence.
In this particular case: from his non-fiction writings, it appears
that although Tom Clancy communicates extensively with the public, he
has, in the course of his research, been permitted to learn a few
things he is not at liberty to fully repeat.
John Savard ( teneerf<- )
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: NIST AES FInalists are....
Date: Mon, 16 Aug 1999 19:08:14 GMT
Douglas A. Gwyn wrote:
> [EMAIL PROTECTED] wrote:
> > Then what you expect is false, since a number of the
> > candidates were excluded for security flaws.
>
> I didn't say that they might not also "rate" similar systems
> with a low score.
Specifically, you said,
| It is to be expected that they would highly "rate" cryptosystems
| similar to the ones they themselves design, regardless of whether
| or not the systems are really secure.
Finding varying degrees of weakness is not
consistent with highly rating them regardless
of actual security.
True, we cannot rule out devastating attacks
unknown to us, nor devastating attacks unknown to
the NSA.
--Bryan
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: "Thomas J. Boschloo" <[EMAIL PROTECTED]>
Subject: Re: NIST AES FInalists are....
Date: Mon, 16 Aug 1999 20:49:06 +0200
"Douglas A. Gwyn" wrote:
>
> "Thomas J. Boschloo" wrote:
> > "Douglas A. Gwyn" wrote:
> > > What has never been explained is the technical design that
> > > could allow such a cipher to be exploitable by the Agency
> > > but not by our enemies. You would think that would be an
> > > unacceptable risk.
> > This is not a problem. The Agency could just make the exploit just small
> > enough for them to crack with an enormous amount of resources, but not
> > for enemies because if would require to much computer time.
>
> Dammit, that's *not* a technical design, that's the same old
> unsupported assertion that "it could be done". *How* could
> it be done?
Sorry, maybe I am spreading FUD
<http://www.hackernews.com/orig/fud.html> I'll try to default more to
'lurking mode' from now on in sci.crypt.
Thomas
--
AMD K7 Athlon 650 Mhz! <http://www.bigbrotherinside.com/#help>
PGP key: http://x11.dejanews.com/getdoc.xp?AN=453727376
Email: boschloo_at_multiweb_dot_nl
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: NIST AES FInalists are....
Date: Mon, 16 Aug 1999 20:15:51 GMT
[EMAIL PROTECTED] (Patrick Juola) wrote, in part:
>.... as opposed to, for example, cryptography as practiced by
>amateurs who don't perform the amount of analysis required of
>academic cryptography. Yes, that makes sense -- academic
>standards are too lax, so let's abandon standards altogether.
>After all, anything designed and tested by academics is obviously
>trivial for the evil spirits of Ft. Meade to read. Something
>cobbled together in a basement, by constrast, is -- nay, MUST BE --
>impenetrable by virtue of the author's ex officio moral superiority.
>And thus doesn't require testing or analysis, or even a readable
>design.
While that is a very valid point, it is also true that many academic
designs do seem to be designed for maximum speed and maximum
simplicity.
This is all very well for establishing the basic validity of a design.
But if one is at all serious about security, while one does wish to
use a sound design based on principles that have been studied by the
experts, one will also have a burning desire to throw in larger
S-boxes, key dependent S-boxes, extra rounds, and constructs which
involve complexities that make analysis virtually impossible.
Can one get away with doing that without an excessive risk of losing
security entirely, by going with an unsound design? I think one can -
if one knows a few basic general principles, and is cautious in the
way one steps away from the well-trodden mainstream.
Thus, I have been so bold as to present for examination my designs -
and not only are they readable, they even come with nice explanatory
diagrams - but I haven't implemented them in any C code just yet -
such as Quadibloc II and Quadibloc III. (And, BTW, I may have to
change Quadibloc III: I'm not sure of SKIPJACK's intellectual property
status.)
John Savard ( teneerf<- )
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: "Thomas J. Boschloo" <[EMAIL PROTECTED]>
Subject: Re: NIST AES FInalists are....
Date: Mon, 16 Aug 1999 21:33:06 +0200
Patrick Juola wrote:
>
> In article <[EMAIL PROTECTED]>,
> Thomas J. Boschloo <[EMAIL PROTECTED]> wrote:
<snip>
> >
> >The whistle blower would however send cyphertext, and would probably be
> >very extensively monitored. This would give him away. It is ok for
> >people like you and me to use anonymous remailers, but probably not for
> >them.
>
> This is nonsense. Contrary to popular belief, the NSA is populated
> by human beings; I lived one floor above an NSA spook while I was in
> college. Even back then, if he had really wanted to blow the whistle
> on anything, he could simply have waltzed into the computer room of
> the local community college and "social engineered" an Email account;
> now he can simply waltz into the local internet cafe and send mail
> to anyone he wants.
>
> And if he was serious enough about the whistle he was blowing, there's
> always the news desk at the Washington Post.
I obviously had a flawed picture of how the NSA works, I thought their
every move would be watched until they retired. And then they would be
sworn to secrecy. Been watching to much James Bond, I am afraid. I hope
the people at the NSA have read '1984' by George Orwell however..
Thomas
--
AMD K7 Athlon 650 Mhz! <http://www.bigbrotherinside.com/#help>
PGP key: http://x11.dejanews.com/getdoc.xp?AN=453727376
Email: boschloo_at_multiweb_dot_nl
------------------------------
From: "Base2" <[EMAIL PROTECTED]>
Subject: Re: compress then encrypt?
Date: Mon, 16 Aug 1999 13:05:05 -0700
> It may be worthwhile pointing out that compression AFTER
> encryption is essentially impossible. Or it should be -- if
> the encrypted text can be compressed, something is likely
> wrong with the crypto.
Well then, by that theory, compressing after encryption isnt a bad way of
checking how secure it is....
But in my mind, with the correct key and message, you could easily get
repeated data ect... or depending on how you did it.
I can see how an incredibly large amount of repeated (encrypted) data, then
compressed with some form of LZ might definitly show some holes.... but
using something such as huffman, which does hash tables of each "char",
doesnt yeild repeated information much at all.
So in my idea of all this bullshit, doing a simple huffman encoding on the
encrypted message, helps greatly, only if the interceptor of the message
doesnt know that you are compressing it (or even making it longer [with the
case of huffman encoding on data with no repetition] ).
Of course, if you want to take that if statement into consideration, if the
interceptor of the message knows how your encrypting your data, and when you
are compressing ect... it really does no good to compress, because it doesnt
hide any information anyways.
-Eric
------------------------------
From: Anton Stiglic <[EMAIL PROTECTED]>
Subject: Re: rsa in other fields
Date: Mon, 16 Aug 1999 16:20:25 -0400
Bob Silverman wrote:
> 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.
Any cryptosystem working in a finite cyclic group Z_pq can
be viewed as working in a finite field F_pq. A field has two operators,
+,* modulo n, a group has just one, * modulo n, you just have to not use
the
+ modulo n operator of the field. Z_pq is in fact composed of a cyclic
group.
So it is not an error to say that RSA works on F_pq.
It would be a big mistake to say that RSA is performed in a Ring, since in
a ring, not all elements are inversible (and we don't necessarily have a
generator).
Anton
------------------------------
From: Jim Felling <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Wrapped PCBC mode
Date: Mon, 16 Aug 1999 14:47:42 -0500
[EMAIL PROTECTED] wrote:
> In article <7p6vus$37ok$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
> > In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
> wrote:
> > >[EMAIL PROTECTED] wrote:
> > >>
> > >> Can someone name me one benefit of Dave's 'super-duper' W-PCBC
> mode?
> > >
> > >A brute-force-attack needs slightly more time since one has to
> decrypt
> > >the whole message to find out whether the key produces garbage or
> not.
> > >The factor is
> > >
> > > (number of blocks) * (number of 'wraps')
> > >
> > >So for a message with 2^6 blocks and with 4 encryptions (4 'wraps')
> > >you'll win 8 bit of strength against brute-force-attacks.
> > >
> >
> > Actually you gain far more than that. Since all of the blessed
> chaining
> > modes only require a few blocks at most to be analyzed your need to
> > look at fewer than a dozen such blocks. Even the NSA is not so stupid
> > that it would look at a whole file for a blind seaerch of a key when a
> > small easy to search segment is all that is needed. Plus if your using
> > special asynchrous digital custom machines it is far easy and less
> hardware
> > intensive to just use a small fragment of the file. This task is much
> harder
> > with "wrapped PCBC".
>
> I agree with the previous post but not this.
>
> Your wrapped-pcbc mode does have the benefit of making keysearch
> slower, but there are easier methods. It's not conceptually harder to
> brute force your method then say CBC, it's just slower (which may be a
> plus). However your method requires the message to be complete before
> encrypting (something which is not always possible).
>
> 1. Use a slow keysetup (ala Blowfish)
> 2. Multiple encryptions
>
> I still don't think your method is any good.
>
> 1. Doesn't promote integrity over say a hash of the message
Agreed.( Allows easy, but slow message corruption detection -- no recovery
though, and allot more overhead)
>
> 2. Doesn't enhance security
True.
>
> 3. Doesn't delay key searches
Actually it does slow them substantially-- his method is an example of an
all-or-nothing encryption method. As such the whole file must be decoded in
any attempt at a guess. On the other hand other such methods of achieving
the same result exist and are substantially faster than his particular
construction.
>
>
> 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: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: rsa in other fields
Date: 16 Aug 1999 20:49:21 GMT
Anton Stiglic <[EMAIL PROTECTED]> wrote:
> It would be a big mistake to say that RSA is performed in a Ring, since in
> a ring, not all elements are inversible (and we don't necessarily have a
> generator).
what happens in the very unlikely case I try to invert 2p ?
------------------------------
** 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
******************************
