Cryptography-Digest Digest #184, Volume #9 Thu, 4 Mar 99 10:13:11 EST
Contents:
Re: Any idea what this might be??? ("Benjamin Johnston")
Re: Scramdisk - paranoia (Anonymous)
PGP 5 and Xemacs crypt.el library (Gildas PERROT)
Re: Scramdisk - paranoia ("Sam Simpson")
Re: Doing It Right: The Next Chip Controversy ("Jay")
Re: Scramdisk - paranoia ("Michel Bouissou")
Re: Elliptic Curve Cryptography (remove_thiscyberway.com.sg (Francis Tan))
Re: Intel/Microsoft ID ("Lassi Hippel�inen")
Re: Factorisation of Polynomials with Matrixes as Coefficients (Bo Lin)
Re: KL-7 Cipher machine (John Savard)
Re: Encrypting Images Using Fractals (Coen Visser)
Re: Doing It Right: The Next Chip Controversy (Ian Woollard)
Re: Scramdisk - paranoia (Gurripato (x=nospam))
Re: Testing Algorithms (Shawn Willden)
----------------------------------------------------------------------------
From: "Benjamin Johnston" <[EMAIL PROTECTED]>
Subject: Re: Any idea what this might be???
Date: Thu, 4 Mar 1999 20:43:48 +1100
>You are right, it seems to be cipher like DES. A friend of mine sent
>the program to me for a challenge and I falsely believed that it would
If you know how to program, discompiling or disassembly may be an option.
If the key is not coded into the program, but rather a constant stored in
the program, you might find the key just by displaying the hex dump of the
program - without requiring programming skills (unless the programmer
already considered that you might do this).
(Assuming that you were sent a program that does the encrypting)
Benjamin Johnston
[EMAIL PROTECTED]
------------------------------
Date: Thu, 4 Mar 1999 11:52:55 +0100
From: Anonymous <[EMAIL PROTECTED]>
Subject: Re: Scramdisk - paranoia
Crossposted-To: comp.security.pgp.discuss,alt.security.pgp
Sorcerer wrote:
> Well, I do have one. it's not serious enough to make me switch, but it
> can be irritating: occasionally, when I first start Scramdisk, I get a
> full reboot, all the way to the BIOS. Retrying it gets me a 0E
> bluescreen error with no reboot a few times; another reboot, and
> everything works fine. I do have lots of stuff, including
> Norton,Realaudio,F-Prot and clipmate running; haven't figured out if
> any of those are causing it. But they don't on the third or fourth
> reboot.
>
> And the only way I can dismount disks is via brutal, which causes a
> blue error screen.
>
> I can live with it, but it's not perfect (yet).
I have similar problems under Win98. If I try to shutdown the system, and
the Scramdisk screen pops up to tell me to dismount Scrandisks first, as
soon as I click a key to continue I get a blue screen fault. Pressing a
key to clear that error results in another blue screen ad infinitum. The
only way out is to manually switch off the machine.
------------------------------
From: Gildas PERROT <[EMAIL PROTECTED]>
Crossposted-To: comp.emacs.xemacs,comp.security.pgp.resources
Subject: PGP 5 and Xemacs crypt.el library
Date: 04 Mar 1999 12:03:44 +0100
Hi,
Does anyone have a patch for crypt.el that causes it to
work in XEmacs 20.4 using PGP 5.0 to visit files?
For instance, if I have a file foo.pgp, if I do
find-file or visit it from dired, it should know how to
decrypt it and how to re-encrypt it if I change and
write it back, using the new command line syntax from
PGP 5.0.
Email response will definitely be appreciated.
Thanks in advance for your help. Gildas.
--
Gildas PERROT, [EMAIL PROTECTED] __o
FranceNet, 28 rue Desaix, 75015 Paris ---_ \<,_
http://www.francenet.fr ---- (_)/ (_)
------------------------------
From: "Sam Simpson" <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: Re: Scramdisk - paranoia
Date: Thu, 4 Mar 1999 11:23:50 -0000
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
Sorcerer,
Sure. I wasn't trying to imply that it was bug free (we are well
aware that it isn't <g>), but it is very certainly an improvement
over previous versions.
I'm concerned about your reports of problems (I suspect a SW
config). Out of interest what HW are you running on?
We would like to tie this problem down to a specific piece of
software if possible, but that may mean disabling / uninstalling
your system piece by piece :-(
Regards,
- --
Sam Simpson
Comms Analyst
http://www.scramdisk.clara.net/ for ScramDisk hard-drive
encryption & Delphi Crypto Components. PGP Keys available at the
same site.
If you're wondering why I don't reply to Sternlight, it's because
he's kill filed. See http://www.openpgp.net/FUD for why!
Sorcerer wrote in message
<[EMAIL PROTECTED]>...
>On Wed, 3 Mar 1999 12:52:24 -0000 "Sam Simpson"
><[EMAIL PROTECTED]> wrote:
>
>>-----BEGIN PGP SIGNED MESSAGE-----
>>Hash: SHA1
>>
>>(Crossposted to c.s.p.d & a.s.p because they may be
>>interested....)
>>
>>I do have to agree.... It is worth some thought.
>>
>>Lets look at some of your individual points:
>>
>>1) Source code for 2.02g. As mentioned in the recent ScramDisk
>>"news letter": (copy available at
>>http://www.scramdisk.clara.net/other/newslet1.txt)
>>
>>"v2.02g
>>======
>>
>>Seems very stable. Since the 17th of November 1998 we have had
>>very few reports of problems. There appears to be some
conflict
>>between the Red Screen mode and certain specific ATI drivers.
>>
>Well, I do have one. it's not serious enough to make me switch,
but it
>can be irritating: occasionally, when I first start Scramdisk,
I get a
>full reboot, all the way to the BIOS. Retrying it gets me a 0E
>bluescreen error with no reboot a few times; another reboot,
and
>everything works fine. I do have lots of stuff, including
>Norton,Realaudio,F-Prot and clipmate running; haven't figured
out if
>any of those are causing it. But they don't on the third or
fourth
>reboot.
>
>And the only way I can dismount disks is via brutal, which
causes a
>blue error screen.
>
>I can live with it, but it's not perfect (yet).
=====BEGIN PGP SIGNATURE=====
Version: PGP 6.0.2
iQA/AwUBNt5tQ+0ty8FDP9tPEQKVbgCcDE9+JCJJCvUZ9XNr6R18EoodRbIAoJEm
TR2o5p3xbYu6B6NfRmYXLMEk
=jg84
=====END PGP SIGNATURE=====
------------------------------
From: "Jay" <[EMAIL PROTECTED]>
Subject: Re: Doing It Right: The Next Chip Controversy
Date: Thu, 4 Mar 1999 06:44:07 -0500
[EMAIL PROTECTED] wrote in message <[EMAIL PROTECTED]>...
>The answer would be to "lock" the ID with a password. (The ability to
>change the password would be on at reset, and turned off - the way the ID
>itself is now - via the BIOS.) Turning it on and off would be done by an
>application separate from your browser.
Much etter yet, a hardware only signal (like a line to a pin on the CPU),
not addressable from software. The user would be told "Press your
confirmation button to verify your ID"
>
There is a product (I can't remember the name) that has a securing ID in a
sealed coinlike device. This can be carried with the user and inserted in
any machine with a receptor, a kind of universal dongle. The difference is,
however that it does not mess with a printer or other port which wasn't
designed for authentication, and the key operation can be shared among many
programs. It would be so much better to be able to access private services
on the net from any machine carrying your id with you instead of having it
locked to a machine.
Jay
------------------------------
From: "Michel Bouissou" <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: Re: Scramdisk - paranoia
Date: Thu, 4 Mar 1999 12:46:08 +0100
Sam Simpson wrote (well, it's in his sigfile):
>If you're wondering why I don't reply to Sternlight, it's because
>he's kill filed. See http://www.openpgp.net/FUD for why!
Saw the "David Sternlight FAQ". Still laughing ;-)))))
--
Michel Bouissou <[EMAIL PROTECTED]> DH/DSS ID: 0x80DBBD8F
Voudriez-vous avoir BIG BROTHER dans votre ordinateur?
N'achetez PAS de Pentium III - Boycottez Intel !!!
Renseignez-vous sur http://www.bigbrotherinside.com
------------------------------
From: tanpc@(remove_this)cyberway.com.sg (Francis Tan)
Subject: Re: Elliptic Curve Cryptography
Date: Thu, 04 Mar 1999 11:00:40 GMT
On Wed, 03 Mar 1999 18:50:30 -0500, nobody <[EMAIL PROTECTED]>
wrote:
>I am searching for some "down-to-earth" information about elliptic curve
>cryptography. I am not well-educated in any area of cryptology--in
>fact, I am quite new to the field. I'm interested in doing a project on
>E.C.C. Is there any good information available that doesn't require a
>PhD to understand it? Where should I start my study in this area of
>cryptography? Any information would be greatly appreciated.
>Thanks, Jon
>Re: [EMAIL PROTECTED]
Get this book
http://www.manning.com/Rosing/index.html
It provides an excellent introductory on the mathematics aspect as
well as discussion on various implementation of ECC, over GF(2^m),
GF(p)
It comes with source codes for you to study on and provides some real
practical applications for learning. Thereafter you should read on
the P1363 and crypto papers, etc.
I wish I have this book when I started off on my project 1 year back.
Dr Mike even has a discussion forum in the webpage.
Francis
------------------------------
From: "Lassi Hippel�inen" <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: Intel/Microsoft ID
Date: Thu, 04 Mar 1999 13:45:19 +0200
Microsoft will start a new marketing campaign with the slogan "We know where
you were today."
(Nicked from the rec.humor.funny newsgroup.)
-- Lassi
------------------------------
From: Bo Lin <[EMAIL PROTECTED]>
Subject: Re: Factorisation of Polynomials with Matrixes as Coefficients
Date: Thu, 04 Mar 1999 11:39:36 +0000
Many thanks to Peter L. Montgomery's kind response.
I think the X is assumed to commute with all matrices after I made a double
check because the X is an indeterminate. They claim the problem could be more
difficult than integer factorisation according to the following observations:
(1) It is difficult to define inversion for matrix polynomials.
(2) The existence of zero factors makes it even worse, i.e. it is possible to
have A*B = 0 for both A <> 0 & B <> 0.
(3) If there do exist an algorithm to factor a matrix polynomial, unlike
integer factorisation, the result is not unique. For example, let C(X) =
A(X)*B(X), the factorisation of C(X) could be D(X) and E(X) with C(X) =
D(X)*E(X).
All the above observations seem reasonable but I'm not sure if their claim is
true.
If anyone can give any help or comments, just like Peter, I should be very
grateful.
Best regards,
Bo Lin
Motorola
Peter L. Montgomery wrote:
> Since matrix multiplication is non-commutative, we need
> to be very careful when we define polynomial arithmetic. For example, if
> A1*X + A0 and B1*X + B0, then their product is
>
> A1*X*B1*X + A1*X*B0 + A0*B1*X + A0*B0
>
> We can multiply A0*B1 and A0*B0, but cannot simplify the first
> two terms A1*X*B1*X and A1*X*B0 unless we assume that the
> variable X commutes with all matrices. The number of terms
> in the product grows very fast.
>
> If you do specify that X commutes with all matrices,
> you can simplify the products. But we lose many familiar
> polynomial properties, such as the degree of a product
> being the sum of the degrees (unless one input is the zero polynomial).
> For example, if M^2 = 0, then
>
> (M*X + I)*(-M*X + I) = -M*X*M*X + I = I (I = identity)
>
> so we can multiply any other factorization by (M*X + I)*(-M*X + I),
>
> In article <[EMAIL PROTECTED]>
> Bo Lin <[EMAIL PROTECTED]> writes:
> >As we know that integer factorisation plays an important role in public
> >key cryptography such as RSA security highly relies on the difficulty of
> >integer factorisation. Although there is no efficient algorithm for
> >integer factorisation, there are many efficient algorithms for
> >polynomial factorisation. For example, polynomials with rational
> >coeffients can be factored by the famous LLL algorithm and polynomials
> >with GF(q) coefficients can be factored by Berlekamp method. Some people
> >suggested another prolem to me that is the factorisation of polynomials
> >with matrixes as coefficients in which each entry of a matrix is either
> >0 or 1, i.e. an element of GF(2). They claimed that the problem could be
> >more difficult than integer factorisation because it appears that there
> >is no straightforward method to do or even define division (or
> >inversion) over matrixes no matter of the poor record of other
> >polynomials in factorisation. An inversion is inevitable in doing
> >factorisation.
> >
>
> --
> [EMAIL PROTECTED] Home: San Rafael, California
> Microsoft Research and CWI
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: KL-7 Cipher machine
Date: Tue, 02 Mar 1999 21:43:37 GMT
[EMAIL PROTECTED] (RREYNARD) wrote, in part:
>I have a photo of the KL-7 Cipher machine that shows a switch on the lower left
>hand portion of the machine next to the 'typewriter' keyboard. Does anyone know
>what that switch does or how is it used in the operation of the KL-7?
As far as anyone who knows the answer is concerned, they probably
would be unwilling to answer the question - the machine hasn't been
declassified yet. My suspicion is, though, that it's the switch that
picks "enciphering" or "deciphering" mode.
Actually, there's a KL-7 on display at an Air Force museum -
http://www.afca.scott.af.mil/pa/public/vcphoto5.htm
the photo is clearer than the one at the Haida web site, but there is
no labelling on the knob.
John Savard (teneerf is spelled backwards)
http://members.xoom.com/quadibloc/index.html
------------------------------
From: [EMAIL PROTECTED] (Coen Visser)
Subject: Re: Encrypting Images Using Fractals
Date: 4 Mar 1999 12:19:18 GMT
[EMAIL PROTECTED] (wtshaw) writes:
>> Fractals and encryption is a fascinating topic! Is there active
>> research in this area?
>> Gary Huntress
>> [EMAIL PROTECTED]
>Since you are doing it, I guess there is. Make it actually work in code
>if you can, and, as simply as you can, before trying to write the
>ultimate; something generic might be scaled up.
>I've seen fractals come up before, mainly requests for info.
The problem with using chaotic systems (and fractals) for encryption is that
they have many stable points/area's with regular behaviour. So not just
any chaotic system can be turned into an encryption system.
Regards,
Coen Visser
------------------------------
From: Ian Woollard <[EMAIL PROTECTED]>
Subject: Re: Doing It Right: The Next Chip Controversy
Date: Thu, 04 Mar 1999 12:33:30 +0000
Reply-To: [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
>
> Let us assume that the pundits are right, and the trend will be towards
> giving the home PC the ability to present *controlled content* - it will
> be possible to download copyrighted works cheaply from the Internet,
> because their owners are secure in the knowledge that your home PC cannot
> misuse or copy them.
>
> Besides putting a serial number in the CPU chip, what else is going to be
> required to achieve that dream?
>
> The answer is: giving chips the ability to execute programs that aren't
> merely "hard to disassemble", but which are actually encrypted - and
> decrypted on the chip.
This isn't nearly sufficient or even the best way to do it. You are
thinking chips when you should be thinking 'system'. What would happen
if somebody made a version of the chip that decrypted the program
and then didn't throw away the decrypted code afterwards???
In order for a PC to even have a hope of protecting the content, really
hard top to bottom security in the PC is required.
This means that not only the BIOS, the operating system, the
application software that runs on it, the windowing system, and the
system bus (think PCI slots), the disk drivers etc. etc. etc.
You also have to start worrying about people screen grabbing the data
into another computer, bypassing all of the encryption entirely.
So, basically content protection is nearly impossible.
There are some techniques that can minimise the chances of theft, but
they are all defeatable. Still, for your average Joe Public there's
some tricks that will make it a real nuisance to steal your stuff.
One that is becoming more useful is to download just a client
program (using java or whatever) that needs to talk to a server
across the net to work properly. Then you make sure that the
same person is only using the service at most once at a time.
That helps for things like video, books, audio and miscellaneous
services.
Still, the client is attackable whilst on the pc, and for some content
this is a fatal flaw. Having the server which is under your
physical control helps a lot though.
> John Savard
--
-Ian ([EMAIL PROTECTED])
2 Secrets to success: 1. Don't tell everyone what you know.
------------------------------
From: [EMAIL PROTECTED] (Gurripato (x=nospam))
Subject: Re: Scramdisk - paranoia
Date: Thu, 04 Mar 1999 12:08:58 GMT
On Wed, 03 Mar 1999 12:04:25 GMT, [EMAIL PROTECTED] wrote:
>From my experience of Scramdisk it appears to be a very well written program.
>However, here is an interesting little thought to get the paranoia going. If
>the government were concerned about encryption then what would be the best
>way to gain access to protected data? One way would be to introduce a piece
>of free software to the general public which appears to offer strong
>protection but also include a back door which would allow them access to any
>encypted file - perhaps by including the password at a specific point within
>the file. I'm not suggesting scramdisk is such a program but it's a definite
>possibility. So far I have not seen a posting from anyone claiming to have
>checked out the source code. Also, why has the source code for the latest
>release not be published? It was claimed that they were interim releases but
>I don't see why it would be a problem zipping up the source code anyway.
>
>You have to agree that it's worth some thought.
>
Too much an effort in order to eavesdrop diehard crypto users
who do know how to protect themselves. But if you want to target the
general user community (those who prefer a fancy screen to a secure
crypto-program), there are more rewarding targets: Netscape�s Fortify
patch, S/MIME implementations, pseudosecure SSL connections,
not-so-random number generators (hey, Intel), etc. And, or course,
freeware copies of PGP/PGPdisk. Who knows whetre PGPckt, or PGPi,
comes from? Who is behind replay.com? Is Schumacher under the NSA
payroll?
Not that I am accusing anybody. Just a little overdose of
healthy paranoia...
------------------------------
Date: Wed, 03 Mar 1999 14:25:32 -0700
From: Shawn Willden <[EMAIL PROTECTED]>
Subject: Re: Testing Algorithms
Withheld wrote:
> In article <[EMAIL PROTECTED]>, Darren New
> <[EMAIL PROTECTED]> writes
> >> What I meant to say was that computing power at the time was
> >> insufficient for a brute-force crack to be viable, rather than any
> >> implication that DES was claimed to be unbreakable forever.
> >
> >Well, of course it's viable, no matter how weak your computer is. You
> >could crack a DES key on a single Apple-II, if you wanted to wait long
> >enough. With a 256-bit key, you can't brute-force it no matter how fast
> >your computers run, quantum computing tentatively excluded.
> I think you meant to say "possible" there. Theoretically, yes a 1MHz
> Apple II could crack it if you gave it a few billion years. For most
> purposes the information would be of academic interest after that, hence
> the term "not viable" rather than "not possible"
>
> As to whether or not we will ever have the computing power available to
> brute force a 256-bit key, take a guess - who knows what breakthroughs
> are around the corner?
You should take a look at the section in Schneier's book on thermodynamic
limitations to brute-force attacks. He assumes an ideal computer, one in
which the energy required to change the value of one bit in the processor is
the smallest possible -- namely the quantum unit. He then calculates the
amount of energy required to run a 256-bit counter through all possible
states, and then compares that amount of energy to the output of the sun.
My memory isn't the best but I believe the answer was that this ideal
computer would require the full output of our sun for several years just to
count through all possible 256-bit keys. Of course, to be useful, this
computer would also have to perform a trial decryption with each key.
Looking at it another way: Let's assume that the Moore's law continues
unabated indefinitely (an unlikely proposition, but fine). This means that
processor speed will double every 18 months. Suppose that we can currently
test one billion keys per second. So, the time required to brute-force a
256-bit key would 2^201 years in 1999. Extrapolating out, we find that in
2300 we should have a processor capable of brute-forcing a 256-bit key in
less than a year.
Okay, what would that processor look like? In order to maintain Moore's law
over the last 20 years, it has been necessary to double the size of the
silicon every four years. 300 years from now, that means your key-cracking
processor will be 2.7 million kilometers square. Actually, it will probably
be a cube a few hundred thousand kilometers on a side. Powering and cooling
this baby will be a trick.
Unfortunately, even that assumes that the transistor density continues
increasing at the rate it has, which would mean your key cracker would have
transistors smaller than an electron, which is going to be an interesting
technical challenge to say the least.
256-bit symmetric keys are and always will be secure against brute-force
attacks.
Shawn.
------------------------------
** 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
******************************
