Cryptography-Digest Digest #398, Volume #10 Tue, 12 Oct 99 02:13:02 EDT
Contents:
Re: Block encryption with variable keys
Re: Block encryption with variable keys
Re: help breaking this cipher (John Wasser)
Re: Which encryption for jpeg compressed pictures? (Dan Day)
Re: Layperson Q: how long to crack 32-bit RSA? (Hideo Shimizu)
Re: Layperson Q: how long to crack 32-bit RSA? (JPeschel)
Math courses good for cryptography (Breidgel)
Re: where to put the trust (Tom St Denis)
Re: Public Key crack without factorising (David A Molnar)
Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column ("Trevor
Jackson, III")
Re: Block encryption with variable keys (wtshaw)
Re: Compression of encrypted data (wtshaw)
Re: classifying algorithms (wtshaw)
Re: on linear keyspaces ("Douglas A. Gwyn")
How vulnerable is... (Rebus777)
Re: where to put the trust (wtshaw)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] ()
Subject: Re: Block encryption with variable keys
Date: 12 Oct 99 01:02:46 GMT
Mok-Kong Shen ([EMAIL PROTECTED]) wrote:
: On the other hand, PRNGs are
: essential to stream encryption, even for those that are lazy.
As Douglas Gwyn pointed out, a stream cipher could also operate like this:
XOR a block of plaintext with the previous ciphertext block, after it is
enciphered by means of DES. (He was, however, not thinking of a mode
of DES, but other systems specifically oriented to stream cipher use.)
Such a stream cipher is self-synchronizing, as well as having good error
recovery.
So one *can* do stream encryption without a PRNG.
John Savard
------------------------------
From: [EMAIL PROTECTED] ()
Subject: Re: Block encryption with variable keys
Date: 12 Oct 99 01:08:11 GMT
Bruce Schneier ([EMAIL PROTECTED]) wrote:
: I can't really tell you why NIST wanted a block cipher over a stream
: cipher. I believe it was because DES is a block cipher, and they
: didn't want the new standard to be too different. I argued that we
: would be better served with a stream cipher.
I think I understand the reasoning that is going on here.
For one thing, the public state-of-the-art in block ciphers is better
advanced than that in stream ciphers.
For another, the transformations involved in using a block cipher to
produce a stream cipher are both more trivial, and more likely to retain
the inherent security of the design, than the transformations by which a
stream cipher could be used to produce a block cipher.
And a black box that performs a block cipher algorithm may also be seen as
easier to validate, and requiring less care and feeding.
That last is perhaps the main point: a block cipher *can* be used in modes
that do not require an IV (initialization vector), and a stream cipher
cannot. (Yes, that too is an oversimplification...) Since for some
applications (i.e. in-place disk encryption) no expansion of the
plaintext can be tolerated, therefore a block cipher.
John Savard
------------------------------
From: John Wasser <[EMAIL PROTECTED]>
Subject: Re: help breaking this cipher
Date: Mon, 11 Oct 1999 21:23:48 -0400
[[ This message was both posted and mailed: see
the "To," "Cc," and "Newsgroups" headers for details. ]]
<[EMAIL PROTECTED]> wrote:
> I have the ciphertext that I would like to break.
> Basically, I would like to reverse engineer the algorithm.
>
> I post (below the dashed line) the data that might be of help.
> Given that data can you tell me the following:
> 1.For this plaintext :8372036303776544
> and this encryption key:97414
> What is the ciphertext? qmriklpngnpqqlom
>
> 2.For this ciphertext: krojqkjonmlsnkrk
> the key is the same as above
> What is the plaintext? 2843620472393472
>
> If you need more data then please let me know.
Plenty of data for the key 97414. Not enough to easily see how
the encoding table relates to the "key".
97414 -> ijkgk
91672 -> iedci
83616 -> hgcgm
Looks like the initial 8 and 9 map to 'h' and 'i' but the second
column doesn't map so neatly: 1->'e' matches 3->'g' but then
7 should map to 'k', not 'j'. The third column has two mapings
for 6, neither matching 4->'k'
> If you think you know how this algorithm works please let me know.
I think I know.
> Key: 97414
> 0 i j k g k i j k g k i j k g k i
> 1 j k l h l j k l h l j k l h l j
> 2 k l m i m k l m i m k l m i m k
> 3 l m n j n l m n j n l m n j n l
> 4 m n o k o m n o k o m n o k o m
> 5 n o p l p n o p l p n o p l p n
> 6 o p q m q o p q m q o p q m q o
> 7 p q r n r p q r n r p q r n r p
> 8 q r s o s q r s o s q r s o s q
> 9 r s t p t r s t p t r s t p t r
8 3 7 2 0 3 6 3 0 3 7 7 6 5 4 4
q m r i k l p n g n p q q l o m
k r o j q k j o n m l s n k r k
2 8 4 3 6 2 0 4 7 2 3 9 3 4 7 2
------------------------------
From: [EMAIL PROTECTED] (Dan Day)
Crossposted-To: comp.security.misc,comp.graphics.algorithms,comp.compression
Subject: Re: Which encryption for jpeg compressed pictures?
Date: Tue, 12 Oct 1999 01:55:13 GMT
On Wed, 06 Oct 1999 07:53:40 -0700, Samuel Paik <[EMAIL PROTECTED]> wrote:
>> I need an encryption which is
>>
>> 1. absolutely secure. If you have the original and the
>> encrypted file, it must be impossible to proof, if
>> one is the encrypted version of the other.
>
>No such thing.
Maybe I'm missing something, but why not?
If you're objecting to the word "impossible", I understand
your rejection. Is this the case, or are you saying that there's
encryption method which makes it "really difficult" to determine
whether a given encrypted text was produced from a given plaintext?
If that's your statement, I don't understand.
--
"How strangely will the Tools of a Tyrant pervert the
plain Meaning of Words!"
--Samuel Adams (1722-1803), letter to John Pitts, January 21, 1776
------------------------------
From: Hideo Shimizu <[EMAIL PROTECTED]>
Subject: Re: Layperson Q: how long to crack 32-bit RSA?
Date: Tue, 12 Oct 1999 11:11:26 +0900
32-bit RSA can be broken without computers.
Hideo Shimizu
TAO, Japan
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Subject: Re: Layperson Q: how long to crack 32-bit RSA?
Date: 12 Oct 1999 02:40:07 GMT
Roy Pardee <[EMAIL PROTECTED]> writes:
>I've got a database app that I'd like to use for a multi-site medical
>study. My app relies on microsoft Access 97 replication, which sends
>32-bit RSA encrypted 'message files' via anonymous ftp.
Don't you mean one of RSA's RC-n ciphers?
A 32-bit RSA number can be easily factored, a 32-bit RC-n
encrypted message brute-forced.
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: Breidgel <[EMAIL PROTECTED]>
Subject: Math courses good for cryptography
Date: Tue, 12 Oct 1999 02:38:28 GMT
What are some good college math courses for someone interested into
getting into cryptography? I was thinking about Advanced Differential
Equations, Advanced Calculus II, Mathematical Modeling, Algorithms and
Applied Combinatorics. Any better or different suggestions?
Thanks,
Erik
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: where to put the trust
Date: Tue, 12 Oct 1999 02:43:37 GMT
In article <wovM3.96$[EMAIL PROTECTED]>,
"Adam Durana" <[EMAIL PROTECTED]> wrote:
> It is silly to blindly believe an expert. Comparing doctors to 'the
> experts' is a bad comparison at best. Doctors provide you with proof and
> explainations for thier diaginosis. People who publish algorithms provide
> the details to them, and reasons they believe it to be secure. But there
> are so many possiblities in this field. Also authors of algorithms are not
> required to be truthful with you like Doctors are. Doctors provide you with
> information which has been proven by the test of time in most cases. Many
> algorithms use new ideas and methods which have been around for a while and
> are considered secure. So its foolish to just believe someone because of
> thier reputation.
>
It's funny you say that. Most of what doctors know is based on time tested
trial and errors procedures. Some of it's educated guesses and approaches...
The same is true for cryprography.
You say doctors know what they are doing, the truth of the matter is there is
still lots to learn. We may know mainly 1% of how the body works with
elements of nature. That's about it. When a doctor says 'use this' it will
fix it. The truth is '99% of the time' in trials it works, and the patients
don't die. It must be good. For example doctors 30 years ago and today
would not really be compatible. What was fact 30 years ago is myth today.
The same is for crypto.
Your blind faith in doctors is un-nerving to say the least.
My point was though, cryptography has experts just like any field, and to get
good crypto, you look at the experts.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Crossposted-To: alt.anonymous,alt.privacy
Subject: Re: Public Key crack without factorising
Date: 12 Oct 1999 02:56:14 GMT
In sci.crypt Kayo Limner <[EMAIL PROTECTED]> wrote:
> Do you folks on sci.crypt know anything about this?
first off, I really wish he didn't denote the public key by "D", and the
private key by "E". He also gets slightly confused in the middle and
switches them. (she?) So here's a go at redescribing the method using my
notation.
^ = exponentiation. NOT XOR.
n = product of two primes p, q
e = public exponent of n
d = private key, congruent to e^-1 mod phi(n)
M = message.
C = ciphertext = M^e mod n
This guy's idea :
1. Get access to M, n, and e. (so far so good)
2. Create the set V of all multiples of n.
So for n = 65, V = {0, 65, 130, ...}
3. Create the set S of all numbers in V plus the ciphertext C.
For C = 2,
S = {2, 67, 132, 197 ...}
Then there is something about how we need to solve
an equation where the "d"th root of some s in S equals M, d unknown.
His scenario is a chosen plaintext attack, so M is known in this case.
We're trying to recover d.
N.B. that this is equivalent to factoring the RSA modulus, which means
it's a very strong attack if it works. Here I mean "strong" as opposed
to other attacks which recover the message without actually getting
the private key.
Then there's a claim that "N will be very large, and this will limit
the number of S values we can try." I'm not sure where he's going
with this -- maybe he's trying to reduce the problem to taking
roots over the integers, by considering all plausible values of
k in the equation m^e = kn + r?
If that is the case, I have a suspicion that for the required
values of k, the number you'll need to deal with from his set S is going
to be a bit big...
...but probably more serious is the fact that I'm not convinced that
this method would even recover d, since we're no longer working
mod n. For if we were working mod n, then it would be really silly
to take all the values in S separately, since they're all congruent
to C by construction and we have the original RSA problem.
I'm not at all sure that just trying to find the correct root over the
integers will recover the private key, for any value s in S...as opposed
to just giving you the public key e right back.
-David
------------------------------
Date: Mon, 11 Oct 1999 23:13:09 -0400
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Dan Day wrote:
> On Mon, 11 Oct 1999 10:26:25 -0700, Sundial Services <[EMAIL PROTECTED]>
> wrote:
> >For instance, at one university I tried to sysop for, I couldn't sleep
> >one night so I tried to log in... and couldn't! Five minutes later my
> >password worked -- and lo, "root" was logged on elsewhere. It turns out
> >that students, who also couldn't sleep, discovered that the password
> >file was unprotected. They simply replaced it, logged on, quickly moved
> >it back. The fact that I discovered the hole was quite by accident.
> >Not a good analogy, I realize, but the point is that the possibility of
> >this "move the iron door out of the way, go inside, put the iron door
> >back" attack had simply never occurred to me. Much less that people
> >were doing it. I changed root-passwords all the time and deceived
> >-myself- into thinking the system was secure.
>
> We pulled a similar dodge back when I was in college... On a
> PDP 11/70 with the RSTS/E timesharing system, the following properties
> held:
> 1. Only a "privileged" account could set the bit on an executable
> file which enabled the executable to perform privileged operations
> even when run by a non-privileged user. (This is how a lot of
> the system software and features were implemented.)
> 2. If a non-privileged user tried to compile a new (rogue) executable
> "into" the existing "priviledged-bit-on" executable, the system
> wisely turned off the "privileged bit".
>
> Sounds reasonably secure, no? No.
>
> One day, I hit upon the following simple scheme to crack the system
> wide open:
> 1. Compile program "A", which would perform any nefarious act
> I wanted to perform if only the "privilege bit" were set.
> 2. Search the system for any privileged executable that had the
> read-write flags enabled, and that was at least as large
> as program "A". Call this program "B".
> 3. Write a quickie "BASIC" program that opened "B" as a data
> file and copied all of its bytes to temporary file "C".
> 4. Use the same BASIC program to copy the byte contents of
> "A" into "B". This, amazingly enough, left the privileged
> bit of "B" still on.
This is almost exactly the technique used to crack multics, which was designed from
the ground up to be secure including hardware memory protection. The only
difference is that the multics crack used a hole in the memory protection hardware
to create trojans out of privileged programs. When a user activated a trojan it
would first ransacked the users file space looking for top secret files and then
copy the original progam overitself to perform the requested operation..
>
>
> I now had my own rogue program existing under name "B", and privileged,
> and could perform absolutely any operation of which the system was
> capable, including creating my own privileged login.
>
> Once I opened the door, it was a simple matter to then get the original
> contents of "B" out of temporary copy "C" and stuff them back into
> "B" where they belonged, leaving the system as it had been originally
> (more or less...)
>
> Clearly, this was *not* something that the system developers had
> counted on... They were apparently under the misconception that
> only the compiler would be writing to executable files.
>
> Sadly, I lacked the dishonest nature which would have enabled me
> to change my grades, or put myself on the college payroll system,
> so it was little more than an academic exercise, but still...
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Block encryption with variable keys
Date: Mon, 11 Oct 1999 21:27:45 -0600
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] () wrote:
> Since for some
> applications (i.e. in-place disk encryption) no expansion of the
> plaintext can be tolerated, therefore a block cipher.
>
Actually, most files have lots of dead space at the end. And, it is not
too difficult to cut the amount to a dimished amount that is normally
written to a sector unencrypted, thus allowing a marginal increase is size
when encrypted.
You can be intolerant if you make no provisions, but that in a
self-induced problem.
--
Figures lie, and liars figure.--Daria Dolan
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Crossposted-To: comp.security.pgp.discuss,alt.security.pgp
Subject: Re: Compression of encrypted data
Date: Mon, 11 Oct 1999 21:46:50 -0600
In article <[EMAIL PROTECTED]>, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:
>... On the other hand, I don't think that anything one
> enciphers with a modern good cipher, say, DES, could be compressed
> to any non-trivial amount (say to less then 98%). It would be
> interesting if someone could show certain actual figures. The fact
> that one attempts to crack DES with such sophisticated methods as
> differential analysis and not frequency analysis of ciphertext
> lends essential heuristic support to my conjecture.
>
I can't call it good, was good, OK. It is interesting. The fact that it
takes such little data to crack it makes it trivial. And, that will not
improve as computer power mushrooms, we ain't seen nothing yet.
--
Figures lie, and liars figure.--Daria Dolan
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: classifying algorithms
Date: Mon, 11 Oct 1999 21:40:33 -0600
In article <7tt58k$2jk$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (David Wagner) wrote:
> We can quibble over definitions and classifications at the boundary all day
> long, but it's worth keeping in mind that most algorithms in the open
literature
> fall clearly into one of two camps: either the "stream cipher" camp or the
> "block cipher" camp. Very rarely do you see one that falls "in the middle".
>
> The two camps have a very different feel to them. In general, the
"block cipher
> attacks" work against most "block ciphers" but rarely work against
"stream ciphers";
> and vice versa for the "stream cipher attacks". (Caveat: As far as I
can tell.)
>
> Thus, even if the line between the two camps is a bit fuzzy, in practice it
> doesn't matter, because (so far) there's been no confusion in thinking of them
> as two distinct classes of ciphers.
Then, I bring along a big exception to both classes that seems to demand
be a special class and depending on how you look at it is one of the two,
both and, neither. Such an algorithm does not fail to function just
because you can not definitively classify it. There must be others that
don't even fit the now three. Yes, I am aware of more than three, but some
and NSA, to drop a name of those that like status quo, desires a
manageable two.
--
Figures lie, and liars figure.--Daria Dolan
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: on linear keyspaces
Date: Tue, 12 Oct 1999 03:22:45 GMT
Tom St Denis wrote:
> In article <[EMAIL PROTECTED]>,
> "Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
> > Tom St Denis wrote:
> > > Uh, frequency analysis hardly works against block ciphers of 64-bits
> > > or 128-bits.
> > Sure it does. Consider: A typical ASCII text file has several very
> > strong statistical biases, for example all the high-order bits are 0,
> > and the low-order bits are more likely to be 1 than 0 for Western
> > languages (a property that has a lot of uses). Not every design of
> > a 64-bit block cipher obliterates all evidence of that input bias.
> ...
> BTW frequency analysis is where you count the frequency of output blocks and
> try to correlate them to inputs blocks for a given language.
Well, if that's what you meant, then your original comment about it
was irrelevant, since I wasn't talking about such a stupid technique.
------------------------------
From: [EMAIL PROTECTED] (Rebus777)
Subject: How vulnerable is...
Date: 12 Oct 1999 04:05:02 GMT
How vulnerable is the "average encrypted binary"?,
with all the different software implementations of DES
that are all somewhat different, because of slight
programing changes to the algo, different kinds of feedback,
chaining and header setups. Some don't even have headers or
the headers are encrypted and therefore leave no tell.
We all say that a DES file can probably be cracked by the
NSA in just a few hours. My question is: Just how realistic
is this statement if the NSA is dealing with a binary file
that it got off of a floppy or the internet and it does not
know the program that encrypted it or even that it is encrypted
with DES? My guess is that this is a much harder problem for
them than we seem to think it is. Just identifing the animal
that they have could be a very large task.
I assume that for each program that they do have catalogued,
they have to write some sort of interface program to deal with
all the above stated differences, before they can even start a
brute force or any other kind of attack?
These comments can apply to any cipher, however the NSA would
probably be in even more trouble, because I don't think they can
crack Blowfish in a few hours.
I'm NOT advocating strength by obscurity, so
don't jump on me about that, please...
-RSC
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: where to put the trust
Date: Mon, 11 Oct 1999 22:25:24 -0600
In article <wovM3.96$[EMAIL PROTECTED]>, "Adam Durana"
<[EMAIL PROTECTED]> wrote:
>.. So its foolish to just believe someone because of
> thier reputation.
As the old saying goes, trust everbody but cut the cards.
--
Figures lie, and liars figure.--Daria Dolan
------------------------------
** 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
******************************
