Cryptography-Digest Digest #189, Volume #11 Wed, 23 Feb 00 21:13:01 EST
Contents:
Re: John McCain Encrypt? (ChenNelson)
Re: Compression in the Real World (Mok-Kong Shen)
Re: Processor speeds. (Mok-Kong Shen)
Re: EOF in cipher??? (Bryan Olson)
Re: DES algorithm (John Savard)
Re: DES algorithm (John Savard)
Re: DES algorithm (John Savard)
Re: NSA Linux and the GPL (John Savard)
Re: DES algorithm (JPeschel)
Re: DES algorithm ([EMAIL PROTECTED])
Re: OAP-L3 Encryption Software - Complete Help Files at web site (Tim Tyler)
RSA private key representation w/3 primes ([EMAIL PROTECTED])
Re: The solution is Open Source! ("John E. Kuslich")
Re: Passwords secure against dictionary attacks? (David A Molnar)
Re: Question about OTPs (Tim Tyler)
Re: NIST, AES at RSA conference (Tim Tyler)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (ChenNelson)
Subject: Re: John McCain Encrypt?
Date: 23 Feb 2000 22:16:53 GMT
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
No one really knows what this "Hipcrime" character is. What is known
is that Hipcrime periodically floods groups he/she/it doesn't like
with garbage such as that posted. At least no one has been able to
determine a message, if there is any. The news.admin.net-abuse.*
groups are the most common Hipcrime target. All in vain, of course,
and this character simply loses the throwaway accounts used for the
abuse.
Later,
Nelson Chen
=====BEGIN PGP SIGNATURE=====
Version: PGP for Personal Privacy 5.5.2
Comment: For public key, go to key server with key ID 0xD28C0DD9
iQA/AwUBOLRc4W1ACZTSjA3ZEQKnvACfX1lSo+Pl7jjLlIY+99vOuADZ6zkAnjhO
vU+AAV2QZSFEs1RMQ4i4qqwX
=X4Jw
=====END PGP SIGNATURE=====
==========================
To earn $0.05 per clickthrough from your web page, please go to
http://www.3wmart.com/ and sign up for our button banner program.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Compression in the Real World
Date: Wed, 23 Feb 2000 23:31:20 +0100
[EMAIL PROTECTED] wrote:
>
> There has been a lot of discusion about 1-1 Hufman compression and how
> it would increase the entropy before encryption .
>
> Sometimes you need real compressors. Lets assume I have a 100 page word
> document which I want to compress and encrypt. If I dont compress it it
> will take take about an hour to transmit ( 1 page of word doc is 40
> KBytes at 5Kb/s sustained connection ).
>
> Working with large documents, 100-500 pages requires real compressors.
>
> I remember meeting the CEO of an Imaging company in San Jose way back in
> the 80īs (forgot the name of the co. Viacom?...I think it merged with
> I2S, Int. Imaging Systems), he claimed he had a text compression system
> with a 100:1 compression ratio...and he was an expert in the field..
>
> And what happened to Compression Labs...they had pretty good imaging
> compression technology.
>
> It seems that no real discusion has taken place of encypting large text
> files . Emails and small messages are a piece of cake. If you are an
> insurance company or a pharmaceutical company, and you have to transmit
> 1000īs of pages then real compression is a must.
A Word document has formatting informations and that increases
the volume over what the pure text characters need. As far as I
am aware, one normally refers to pure text characters when one
talks about a text file. Hence text file compression also refer
to compression of these. If you have really secret messages, what
you want to protect are only the pure text characters. Hence a
question is whether you 'really' have to transmit a Word document
or it suffices to have its contents be transmitted. If you insist
on transmitting a Word document as such, i.e. accepting the
inefficiency incurred by the presence of formatting informations,
then of course you can do that, since a Word document is a sequence
of bytes and you can compress it with any of the lossless
compression schemes to reduce the volume and then apply your
encryption method. For image compression, on the other hand, one
generally uses lossy compressions. Such lossy compression techniques
cannot be applied to the byte sequence of a Word document, because
you cannot recover the original due to the losses. Well, theoretically
you could treat what you see on the screen of the document as a
picture and apply the image compression techniques, but that's a
tremendous waste of resources, since each character would then have
to be represented by a number of pixels and that would cause a large
expansion factor which I believe (though I have no real data to
precisely support my claim) can by far not be compensated by the
fact that the lossy compressions usually have a much larger
compression ratio than the lossless ones. (Afterall, this larger
compression ratio comes from properties of the common types of
pictures which differ from a Word document that is 'treated'
(thought of) as a picture.)
The above is what I can say with my humble knowledge. Experts
in compression may however eventually correct my statements.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Processor speeds.
Date: Wed, 23 Feb 2000 23:31:27 +0100
Mike Rosing wrote:
>
> machines and building a supercomputer from those. At only $200 the 128
> bit machines are pretty cheap for what they do, and I totally agree
Most PCs today have only 32 bit registers. I guess that this jump to
128 bits probably can more than compensate for the slower processor
speed (if any), resulting in substantial benefits especially in doing
multi-precision arithemetic operations. So this appears to be
indeed an interesting project.
M. K. Shen
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: EOF in cipher???
Date: Wed, 23 Feb 2000 22:29:05 GMT
Trevor Jackson, III wrote:
[...]
> But only true in so far as the compiler is conformant with
> modern C standards. There was a time not that long ago
> that compilers did _not_ promise 8-bit bytes.
Thankfully, those days have passed and ANSI/ISO C has taken
over the C world. (Actually the safe assumption is _at
least_ 8-bits in a char.)
> The critical issue is this: why do you care? It is
> perfectly possible to write programs _without_ the
> assumption of 8-bit bytes. Since the assumption gains
> you little there is little value in embedding it in
> code, and significant risk in doing so.
Assumptions based on the minimum magnitudes for values of
the constants in <limits.h> are safe. Programmers can gain
simplicity by relying on them, and portability by not
relying on larger magnitudes.
> One of the related topics was the relationship between
> sizeof(int) and sizeof(char), with the attendant
> assumption that chars are always smaller than
> ints. Sophisticated users might assume <= rather
> than <. But both assumptions are unnecessary.
As noted in another strand of the thread, the int return
value of getc() needs to be able to represent every
character value, plus the distinct EOF value.
--Bryan
--
email: bolson at certicom dot com
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: DES algorithm
Date: Wed, 23 Feb 2000 16:05:09 GMT
Quisquater <[EMAIL PROTECTED]> wrote, in part:
>Sorry. And good reading!
Yes, the article was interesting.
But as a general practice, I think providing an URL one step back from
.pdf files is a good idea.
I'll be interested in the next paper the author promises, about the
AES candidates.
Also, this paper makes more explicit comments about the "larger-key
original DES" that keeps getting rumoured: here, the key was 64 bits,
but the engineers insisted on parity. Unless IBM decides to release
the plans for the "original DES", however, this will still be shrouded
in mystery.
It did, however, contain one inaccuracy. DES came about to secure the
"sensitive but unclassified" data of the _U.S. Government_, not the
general public; that the general public might also secure the data
that they wish to keep private was a side benefit, but the phrase
"sensitive but unclassified" would not be applicable to that.
John Savard (jsavard<at>ecn<dot>ab<dot>ca)
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: DES algorithm
Date: Wed, 23 Feb 2000 16:00:41 GMT
"Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote, in part:
>Not if you "save link as" instead of just default-selecting
>the link. If somebody really has the problem you describe,
>he ought to be aware of that simple solution.
I can do that if the URL is on a web page. But when the URL is in a
USENET article, the only thing I can do with it in a browser is to
type it in in the URL box. Only if Acrobat Reader isn't installed (or
it's on the disk, but the file types aren't registered) do I get the
chance to save the file.
John Savard (jsavard<at>ecn<dot>ab<dot>ca)
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: DES algorithm
Date: Wed, 23 Feb 2000 16:08:24 GMT
Quisquater <[EMAIL PROTECTED]> wrote, in part:
>Sorry. And good reading!
To be specific, this is the URL I would have liked to have seen:
http://www.ams.org/notices/200003/200003-toc.html
but I still thank you for providing _an_ URL, which is more than the
first poster had done!
John Savard (jsavard<at>ecn<dot>ab<dot>ca)
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: NSA Linux and the GPL
Date: Wed, 23 Feb 2000 16:16:01 GMT
"Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote, in part:
>I agree that it was a terrible, inexcusable mistake, and should
>keep anyone from ever again putting Deutsch in a position of trust,
>but I don't see how he can be punished under the law.
Well, at least it is a mistake, and not deliberate espionage - like
that fellow at the DoE has at least been _accused_ of. (Even Americans
of Chinese descent don't usually get convicted of anything without
evidence, at least nowadays.)
I would have thought, though, that there were regulations governing
the procedures to be used in the handling of classified information
that do have the force of law. On the other hand, the lack of an
Official Secrets Act does mean more than merely that the courts can
consider the public interest in a release of classified information,
else the Yardley law would not have been unique.
John Savard (jsavard<at>ecn<dot>ab<dot>ca)
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Subject: Re: DES algorithm
Date: 23 Feb 2000 23:18:29 GMT
[EMAIL PROTECTED] (John Savard) writes:
>I can do that if the URL is on a web page. But when the URL is in a
>USENET article, the only thing I can do with it in a browser is to
>type it in in the URL box.
Highlight the URL, right click, copy, and paste.
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: DES algorithm
Date: 23 Feb 2000 23:24:31 GMT
JPeschel <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] (John Savard) writes:
>>I can do that if the URL is on a web page. But when the URL is in a
>>USENET article, the only thing I can do with it in a browser is to
>>type it in in the URL box.
> Highlight the URL, right click, copy, and paste.
That doesn't fix John's problem at all -- he has to have a link he can
"right click" on before he can do that.
My suggestion for John: Look into the "wget" program -- it will snarf
the file down for you without ever having to start a web browser, and
then you can view the pdf file from your local copy...
--
Steve Tate --- srt[At]cs.unt.edu | Gratuitously stolen quote:
Dept. of Computer Sciences | "The box said 'Requires Windows 95, NT,
University of North Texas | or better,' so I installed Linux."
Denton, TX 76201 |
------------------------------
Crossposted-To: talk.politics.crypto,alt.privacy
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: OAP-L3 Encryption Software - Complete Help Files at web site
Reply-To: [EMAIL PROTECTED]
Date: Wed, 23 Feb 2000 23:20:22 GMT
In sci.crypt David A. Wagner <[EMAIL PROTECTED]> wrote:
: In article <[EMAIL PROTECTED]>, Tim Tyler <[EMAIL PROTECTED]> wrote:
:> Any algorithm that comes with a mathematical proof that it's unbreakable
:> is unlikely to be analysed by the world's leading codebreakers.
:>
:> Instead it is likely to be dismissed out-of-hand - as the output of
:> someone with little idea about the nature of the field.
: Nonsense. Cryptosystems that are provably secure (under some assumptions)
: are published all the time, and broken some of the time.
An "unbreakable" code?? Give me a break! ;-)
This sounds like the same sort of thing as an "ideal" one-time-pad.
It's all very well in *theory* - but in practice it doesn't actually exist.
You can sometimes prove that breaking a code is equivalent to some other
problem that's widely thought to be tricky - but that's *hardly* the same
thing as "unbreakable".
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
Madness takes its toll. Please have exact change.
------------------------------
From: [EMAIL PROTECTED]
Subject: RSA private key representation w/3 primes
Date: Thu, 24 Feb 2000 00:03:21 GMT
Forgive the possibly stupid question, but I am looking
for a statement of the decryption operation and key
representation for RSA with 3 primes that is analogous
to the following 2-prime procedure as articulated in
PKCS#1:
m : plaintext block
c : ciphertext,
e : public exponent,
K : private key : (p,q,dP,dQ,qInv)
where
p, q are the prime factors,
dP : dP*e == 1 mod (p-1)
dQ : dQ*e == 1 mod (q-1)
qInv : q*qInv == 1 mod p
and decryption of c to m is performed thusly:
let m1 = c^dP mod p
let m2 = c^dQ mod q
let h = qInv*(m1-m2) mod p
let m = m2 + h*q
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "John E. Kuslich" <[EMAIL PROTECTED]>
Subject: Re: The solution is Open Source!
Date: Wed, 23 Feb 2000 17:21:44 -0700
Well, ok. My four function calculator is secure too, by that line of
reasoning. And so is my abacus and slide rule.
Although, I'm not sure about my ten fingers...I count them carefully every
morning just to be sure. 10, 9, 8, 7, 6 plus 5 = 11. Yep everything is ok
:--)
Here, try this:
Open Excel 97. Create a file and apply the following password -
"VelvetSweatshop". Save the file and close excel. Now, open excel and open
the just saved file. Batta bing. No password is required. But you applied
a password?????? Look at the file using a hex editor. It IS encrypted
alright!
TRY IT!! No password is required!
Now you get bored with this and you play a little computer game for a while.
This game contains a trojan that accesses a memory resident dll on your
system called Xlintl32.dll. It changes a string in this dll (after it is
loaded in memory) from "VelvetSweatshop" to "VelvetSweatband".
Now all of a sudden Excel demands a password on your excel file. How would
having the source for excel help you? Or even having the source for the
game for that matter. Would you be able to divine the reason for the string
write of "band" to a seemingly innocuous memory location??? Perhaps, or
perhaps not.
I still don't think open source is a solution to security, as much as I like
the concept for many other reasons.
JK
JK
Mike McCarty <[EMAIL PROTECTED]> wrote in message
news:891cj4$73f$[EMAIL PROTECTED]...
> In article <MaUs4.71$[EMAIL PROTECTED]>,
> John E. Kuslich <[EMAIL PROTECTED]> wrote:
> )The "answer" you provide is NOT the answer at all. It is an illusion.
>
> [snip program build]
>
> )You have to execute the compiled code on a machine running an operating
> )system. This O/S will be multithreaded and multitasking so many other
> )processes will be running concurrently (within the limits of the meaning
of
> )concurrency in the O/S context). Now, suppose one of the loaded
libraries
> )your code uses has evil code that breaks your security?
>
> This is untrue, at least in my case. I use MSDOS on my computers at
> home. I have no modem on them. Where is the security breach?
>
> [snip]
>
> )Open source is good for a lot of things, but it does nothing for
security.
>
> Your reasoning is flawed.
>
> Mike
> --
> ----
> char *p="char
*p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
> This message made from 100% recycled bits.
> I don't speak for Alcatel <- They make me say that.
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Crossposted-To: comp.security.misc,alt.security.pgp
Subject: Re: Passwords secure against dictionary attacks?
Date: 24 Feb 2000 01:13:07 GMT
In sci.crypt Alun Jones <[EMAIL PROTECTED]> wrote:
> 'secured' lab where all occupants shared the same password (for different
> user names) and had written it on a piece of masking tape stuck to the top
> of the monitor.
There was a famous case in 1994 or thereabouts in which a British
tabloid reported found out about this sort of thing at British Telecom.
Apparently he applied for work as a temp and ended up scooping up some
interesting post-it notes...
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Question about OTPs
Reply-To: [EMAIL PROTECTED]
Date: Thu, 24 Feb 2000 01:02:44 GMT
Bryan Olson <[EMAIL PROTECTED]> wrote:
: [EMAIL PROTECTED] wrote:
:> Bryan Olson wrote:
:> : [EMAIL PROTECTED] wrote:
:> :> It [The OTP] has about the best possible resistance to
:> :> cyphertext-only attack, that's all.
:>
:> : Not so. The important property of the OTP is "perfect
:> : secrecy", and it maintains this property regardless of the
:> : attacker's a priori knowledge about the plaintext.
:>
:> You /appear/, perhaps, to have misinterpreted my "that's
:> all" as "that's the only attack it defends against".
: Hmmm, I guess I'm still not clear on what you meant. If you
: were limiting "attack" to recovery of information, then
: specifying ciphertext-only is wrong. [...]
This time *I* am not sure what *you* mean.
An "ideal" OTP does resist cyphertext-only attacks about as well as it's
possible to do.
The structure resists other types of attacks to varying degrees. I did
not mean to make any implied statement concerning other types of attacks.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
The cigarette does the smoking - you're just the sucker.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: NIST, AES at RSA conference
Reply-To: [EMAIL PROTECTED]
Date: Thu, 24 Feb 2000 01:26:09 GMT
[complete snip of Ritter's "multiple cypher" schemes]
My 2p worth:
Essentially I thoroughly agree with all this material about multiple
layers of different types of encypherment being an appropriate route to
strength, in the absence of any concrete knowledge about the strength of
our cyphers.
One slight concern with it is that it seems desirable in terms of security
to keep things simple as is possible while retaining strength.
I fear that early implementations of negotiating multiple cyphers between
hererogenous systems are likely to suffer more from security problems due
to bugs than conventional systems.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
The bigger they are, the harder they hit you.
------------------------------
** 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
******************************
