Cryptography-Digest Digest #231, Volume #12 Sat, 15 Jul 00 22:13:00 EDT
Contents:
Re: attack against CBC mode (SCOTT19U.ZIP_GUY)
Re: a file security proposal (Michael Gu)
unambiguous polynomial computation and crypto (David A Molnar)
Re: SECURITY CLEAN freeware text editor in win95 ? (jungle)
Re: Diffie Hellman Primes : Speed Tradeoff Q (Bob Silverman)
Re: Has RSADSI Lost their mind? (Benjamin Goldberg)
Re: General Question on cryptography (Benjamin Goldberg)
Re: xor confusion! (phil hunt)
Re: a file security proposal (phil hunt)
Re: Has RSADSI Lost their mind? (Bill Unruh)
Toronto WebGrrls, Cypherpunks & CPSR Meeting on Privacy & Security (Robert Guerra)
Re: Has RSADSI Lost their mind? (David A Molnar)
Re: unambiguous polynomial computation and crypto ("Scott Fluhrer")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: attack against CBC mode
Date: 15 Jul 2000 23:04:02 GMT
[EMAIL PROTECTED] (Runu Knips) wrote in <[EMAIL PROTECTED]>:
>"SCOTT19U.ZIP_GUY" wrote:
>> If one uses "wrapped PCBC" which treats the whole file as a
>> single block as in SCOTT19U or SCOTT16U this kind of problem
>> goes away.
>
>Well nice but I don't want to keep the whole file which is
>going to get encrypted in memory.
>
Actually it was just easier for me to code it totally in memory
but haveing the whole file in memory is not a requirement for
"Wrapped PCBC"
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website NOT FOR WIMPS **no JavaScript allowed**
http://members.xoom.com/ecil/index.htm
Scott rejected paper for the ACM
http://members.xoom.com/ecil/dspaper.htm
Scott famous Compression Page WIMPS allowed ** JavaScript OK**
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
"The road to tyranny, we must never forget, begins with the destruction
of the truth."
------------------------------
From: Michael Gu <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.system,comp.os.linux.security
Subject: Re: a file security proposal
Date: Sat, 15 Jul 2000 23:23:36 GMT
Kaz Kylheku wrote:
> On Sat, 15 Jul 2000 19:38:49 GMT, Michael Gu <[EMAIL PROTECTED]> wrote:
> >If this has already been done, please ignore this message.
> >
> >I suggest to add file encryption capability to the system ( kernal, or
> >whatever ). The general idea I have is following:
>
> It's spelled ``kernel'' and there are already solutions for this, like
> CFS from AT&T Research or block device encryption.
>
Sorry for the spelling, I am not a computer yet.
>
> > 1. system distinguish whether a file is encrypted or not
> > 2. when access an encrypted file, system will get the key by some
> >means. e.g. prompt for a password, read user config file ...
>
> Hmm, read a plaintext user config file. And what will protect that?
>
Did I say it's a plaintext user config file? Even so, why can't it be protected?
>
> Prompt for a password at access time? What if it's a GUI application?
>
I don't see why a GUI application can not pop up a window.
>
> At one time, some goofballs decided to make low level file access
> calls of an operating system generate prompts at the user. The result was the
> infamous ``abort, retry, fail, ignore'' question of MS-DOS.
>
Well, I am OK with these message, at least they tell you something is wrong. It's
better than something dies without a notice.
>
> CFS has a solution in the form of a command that creates plain-text mapping
> which appears to be an NFS mounted filesystem. The encryption key is held
> within the CFS daemon, which acts as the encryption/decryption agent on
> behalf of the user; the user's application manipulate the plaintext tree,
> and the CFS daemon performs encrypted I/O on the encrypted tree which is
> stored somewhere else, possibly on another machine.
>
> A user can have many trees, with distinct keys. When the user wishes to access
> his or her encrypted directory, he or she invokes the CFS command for creating
> the plaintext mapping. At that time, the password is entered. The program
> passes the authentication to the CFS daemon, which creates the plain view in a
> directory tree that is NFS mounted from the deamon by the user's kernel.
>
> > 3. after having aquired the key, system will handle
> >encryption/decryption transparent to the calling party.
> > 4. when create an file, the function call has an option to make it
> >encrypted.
>
> So each application that creates files has to be modified to support
> this new option in the file creation system call! Good plan!
>
Please try to think more freely! If the system handles password,
encryption/decryption, the application won't even know whether the file is
encrypted or not! Why it has to be modified?
>
> --
> #exclude <windows.h>
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Crossposted-To: comp.theory
Subject: unambiguous polynomial computation and crypto
Date: 15 Jul 2000 23:22:39 GMT
Last term, my professor brought up the connection between unambiguous
computation and one-way functions to show that it may not be possible
to "base cryptography on P vs. NP," because one-way functions exist
iff P != UP, and UP is unlikely to have complete problems. This
is also in Papadimitriou _Computational Complexity_, along with
the usual note that NP-complete problems aren't necessarily hard on
average.
While the worst case vs. average case problem is discussed on sci.crypt
every few months, I don't remember any discussion there or in comp.theory
of the P vs. UP vs. NP problem. The reference given in Papadimitriou is to
a 1988 paper by Grollman and Selman "Complexity measures for public-key
cryptography." The most recent paper in this general area I know of is
1998's "On The Possibility of Basing 'Cryptography' on P \neq NP", by
Goldreich and Goldwasser which doesn't mention UP at all (but does cite
the 1988 paper).
So what happened? Was the question ever satisfactorily resolved, is it
still open, or is it not well formed after all?
In addition, has anyone looked at the formulation of the question about
cryptosystems with an eye towards updating it for randomized cryptography?
The way it's stated, the adversary guesses a plaintext, encrypts it,
and then compares to the ciphertext; this does not seem to be realistic
for a randomized system in which trial encryptions don't work.
Thanks,
-David Molnar
------------------------------
From: jungle <[EMAIL PROTECTED]>
Subject: Re: SECURITY CLEAN freeware text editor in win95 ?
Date: Sat, 15 Jul 2000 19:31:52 -0400
the winvi32 is NOT CLEAN ...
the run report ...
=============================================================================
Installation report: WinVi32 1st run changes
Install program: E:\download\WinVi32 unix type editor\WinVi32\WinVi32.exe
Notification by Real-time reporting
NO CHANGES MADE TO c:\windows\control.ini...
NO CHANGES MADE TO c:\windows\system.ini...
CHANGES MADE TO c:\windows\win.ini...
SECTIONS ADDED TO c:\windows\win.ini: (1)
[Ramo's WinVi]
KEYS ADDED TO c:\windows\win.ini: (8)
[Ramo's WinVi]Height=871
[Ramo's WinVi]Maximized=No
[Ramo's WinVi]RecentDir0=E:\download\WinVi32 unix type editor\WinVi32
[Ramo's WinVi]RecentFile0=E:\download\WinVi32 unix type editor\WinVi32\test
text file.txt
[Ramo's WinVi]RecentFiles=0
[Ramo's WinVi]Width=1092
[Ramo's WinVi]X-Position=53
[Ramo's WinVi]Y-Position=346
NO CHANGES IN Registry
FILES ADDED: (2)
---by process E:\DOWNLOAD\WINVI32 UNIX TYPE EDITOR\WINVI32\WINVI32.EXE
C:\WINDOWS\RECENT\TEST TEXT FILE.TXT.LNK
E:\DOWNLOAD\WINVI32 UNIX TYPE EDITOR\WINVI32\TEST TEXT FILE.TXT
FILES DELETED: (1)
---by process E:\DOWNLOAD\WINVI32 UNIX TYPE EDITOR\WINVI32\WINVI32.EXE
C:\WINDOWS\RECENT\REGEDIT.EXE.SIG.LNK
FILES CHANGED: (1)
---by process E:\DOWNLOAD\WINVI32 UNIX TYPE EDITOR\WINVI32\WINVI32.EXE
C:\WINDOWS\WIN.INI
=============================================================================
JPeschel wrote:
>
> Richard Heathfield [EMAIL PROTECTED] writes, in part:
>
> >jungle wrote:
>
> >> any help for freeware in win95 :
> >> SECURITY CLEAN text editor [ like NOTEPAD ] that can be used to edit
> >> up to 1 MB files ?
> >
> The original poster, if he's interested in vi, might want to try something
> called WinVi at:
>
> http://winfiles.cnet.com/apps/98/text-editors-q.html
------------------------------
From: Bob Silverman <[EMAIL PROTECTED]>
Subject: Re: Diffie Hellman Primes : Speed Tradeoff Q
Date: Sun, 16 Jul 2000 00:03:15 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Mark Wooding) wrote:
> Bob Silverman <[EMAIL PROTECTED]> wrote:
>
> > Huh? They still take O(sqrt(q))! As long as q is large, the
structure
> > of R doesn't matter.
>
> Does the structure of p, containing as it does many small factors, not
> make attacks against the cyclic group of the whole field easier?
Huh? Z/pZ* isn't cyclic. What do you mean by "cyclic group
of the whole field"?
NFS cares nothing about the structure of Z/pZ*. And Pollard rho
only attacks the cyclic subgroup whose order is q.
What do you really mean?
--
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/
Before you buy.
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: Has RSADSI Lost their mind?
Date: Sun, 16 Jul 2000 00:25:48 GMT
Bill Unruh wrote:
>
> In <[EMAIL PROTECTED]> [EMAIL PROTECTED] (phil
>hunt) writes:
> ]>>
> ]>> Couldn't they have used an unemcumbered algorithm such as
> ]>> Blowfish?
> ]>
> ]>Ehrrr... Blowfish is a symmtric cipher (Same single key for encrypt
> ]>and decrypt)
> ]>
> ]>RSA is an assymetric scheme (Public key/private key).
>
> ]Aren't there unencumbered public key algorithms? What does GnuPG use?
>
> Now there are. The DH patent expired in 97 or 98. SSL was much before
> that . RSA expires in two months. Elliptic curve is some time in the
> future. There are no other public key algorithms I know of.
There's also:
Pohlig-Hellman, mentioned at http://www.cyberlaw.com/rsa.html
NTRU, described at http://www.ntru.com/
Cayley-Purser, described at http://www.cayley-purser.ie/
ELGamal, probably described lots of places, but I don't know where.
I don't know which of these are published/patented; you'll have to look
into that yourself.
--
This is the signature worm.
Help me spread by appending me to your signature.
This is the signature worm.
Help me spread by appending me to your signature.
This is the signature worm.
Help me spread by appending me to your signature.
This is the signature worm.
Help me spread by appending me to your signature.
This is the signature worm.
Help me spread by appending me to your signature.
This is the signature worm.
Help me spread by appending me to your signature.
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: General Question on cryptography
Date: Sun, 16 Jul 2000 00:40:23 GMT
Well, if you accidentally create a non-reversible cipher, you can still
use it in cipher feedback (CFB) mode.
Sundial Services wrote:
>
> One of the subtle ideas that John is alluding to is that you might
> *think* that your cipher is strong when in fact it has a weak-link
> that you cannot see.
>
> The Germans lost a war confident that the Enigma machine could not be
> broken -- because after all it really only had one cryptographic
> weakness, namely that a letter could never encipher to itself. But
> that alone was enough to permit a break into Enigma.
>
> You might also inadvertantly create a "cipher" that turns out to be
> non-reversible! :-O
>
> >John Savard wrote:
> >[...]
> > If someone attacking a message of yours can't even *think of* the
> > algorithm you are using, your message would be safe. But the
> > keyspace of ideas like "use FFT" is not really that large. That you
> > are using RSA would likely provide the _real_ security your message
> > has, and that part of the algorithm could likely be inferred by the
> > nature of your previous exchange of keys.
> >
> > Cryptography as it exists today has been shaped by influential
> > writers on the subject. Auguste Kerchoffs made a list of six
> > characteristics the ideal cipher should have. One of them is that a
> > cipher's easily changeable key - rather than the algorithm itself -
> > should be the source of its security.
> >
> ------------------------------------------------------------------
> Sundial Services :: Scottsdale, AZ (USA) :: (480) 946-8259
> mailto:[EMAIL PROTECTED] (PGP public key available.)
> > Fast(!), automatic table-repair with two clicks of the mouse!
> > ChimneySweep(R): "Click click, it's fixed!" {tm}
> > http://www.sundialservices.com/products/chimneysweep
This is the signature worm.
Help me spread by appending me to your signature.
This is the signature worm.
Help me spread by appending me to your signature.
This is the signature worm.
Help me spread by appending me to your signature.
This is the signature worm.
Help me spread by appending me to your signature.
This is the signature worm.
Help me spread by appending me to your signature.
This is the signature worm.
Help me spread by appending me to your signature.
------------------------------
From: [EMAIL PROTECTED] (phil hunt)
Subject: Re: xor confusion!
Date: Sun, 16 Jul 2000 01:20:24 +0100
Reply-To: [EMAIL PROTECTED]
On Sat, 15 Jul 2000 20:06:51 GMT, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>i don't quite understand how the XOR operation works. i was reading
>about it in Applied Cryptography, by Bruce Schneier. the explaination
>was rather brief, so I decided to make a program that generated two
>random integers and XORed them. i understand why the same number twice
>will return zero, but i don't get how 6 xor 3 can be five (that's one
>of the pairs i got). any help is greatly appreciated!
Xor takes 2 bits as input (call them A & B) and produces a 1 bit result (R):
A B R
0 0 0
0 1 1
1 0 1
1 1 0
One useful property of xor is that ((A xor B) xor B) == A. IOW if you
xor something twice with the same value, oyu get what you started with.
Computers typically can do bitwise xor on 16 or 32 bit values; this means
they xor bit0 of both operand to produce bit0 of the result, the same with
bits 1 to whatever the size of the word is.
In binary, 3 = 011
6 = 110
So, xoring:
0 1 1
1 1 0
--------
1 0 1
101 base 2 == 5 base 10.
--
***** Phil Hunt ***** send email to [EMAIL PROTECTED] *****
Moore's Law: hardware speed doubles every 18 months
Gates' Law: software speed halves every 18 months
------------------------------
From: [EMAIL PROTECTED] (phil hunt)
Crossposted-To: comp.os.linux.development.system,comp.os.linux.security
Subject: Re: a file security proposal
Date: Sun, 16 Jul 2000 01:08:05 +0100
Reply-To: [EMAIL PROTECTED]
On Sat, 15 Jul 2000 19:38:49 GMT, Michael Gu <[EMAIL PROTECTED]> wrote:
>If this has already been done, please ignore this message.
It has been done. There's a system that does this for Windows 95, &
which is now being poerted to Linux.
>I suggest to add file encryption capability to the system ( kernal, or
>whatever ). The general idea I have is following:
>
> 1. system distinguish whether a file is encrypted or not
> 2. when access an encrypted file, system will get the key by some
>means. e.g. prompt for a password, read user config file ...
If the password's in a file, doesn'rt that defeat the whole point of
encryption?
> 3. after having aquired the key, system will handle
>encryption/decryption transparent to the calling party.
> 4. when create an file, the function call has an option to make it
>encrypted.
Then it would be up to the application to decide whether the file should
be encrypted. Which means that existing application programs, written
before the encryption system was designed, won't be able to do it.
Better to have that decision made by the encryption subsystem of the disk
control software (with directory-wide defaults, perhaps).
--
***** Phil Hunt ***** send email to [EMAIL PROTECTED] *****
Moore's Law: hardware speed doubles every 18 months
Gates' Law: software speed halves every 18 months
------------------------------
From: Bill Unruh <[EMAIL PROTECTED]>
Subject: Re: Has RSADSI Lost their mind?
Date: Sat, 15 Jul 2000 18:38:50 -0700
> > future. There are no other public key algorithms I know of.
>
> There's also:
> Pohlig-Hellman, mentioned at http://www.cyberlaw.com/rsa.html
Not public key. As far as I know this is a secret key encryption
procedure, where the decryption and encryption keys are different.
> NTRU, described at http://www.ntru.com/
Well, described is a bit strong. There is absolutely no description
However there is a mentionof the patent
US06081597
> Cayley-Purser, described at http://www.cayley-purser.ie/
I believe that this has been shown to be weak (broken). See the postscript to
that article.
> ELGamal, probably described lots of places, but I don't know where.
That is DH (It is the name given to the public key version of DH )
------------------------------
From: Robert Guerra <[EMAIL PROTECTED]>
Crossposted-To: sympatico.general,comp.security.pgp.discuss,alt.privacy,can.general
Subject: Toronto WebGrrls, Cypherpunks & CPSR Meeting on Privacy & Security
Reply-To: [EMAIL PROTECTED]
Date: Sun, 16 Jul 2000 01:56:32 GMT
Toronto WebGrrls, Cypherpunks & CPSR Meeting on Privacy & Security
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
TIME: August 15 at 6:30 pm
PLACE: MetroHall 55 John St, The City Room (1st floor)
(Cross street: King St West - John is just west of University)
Phone: (416) 397-7146 Access Metro: (416) 392-8000
URL: http://toronto.cypherpunks.ca
This meeting is intended as an information session for people at all
levels, in particular for people who use the internet only occasionally.
It's focus is briefly to explain why online privacy is important, what
you can do to protect it..and who you can turn to if there's a problem.
New users will probably get more out of the meeting that those who are
already familiar with the issues and available tools.
Program:
(1) 30-40 min Presentation by the folks from Zero Knowledge Systems
"Privacy/anonymity tool created by Montreal based company"
(2) Either one of the following:
a. 30-40 min presentation by A.K.(Arni) Stinnissen
OR
b. panel discussion with each speaker giving a max 10-15 min
presentation
followed by discussion with:
(1) A.K.(Arni) Stinnissen,
Head, Computer Crimes Division , Ontario Provincial Police
(2) (still to confirm)
--
Robert Guerra <[EMAIL PROTECTED]>, Fax: +1(303) 484-0302
WWW Page <http://crypto.yashy.com/www>
PGPKeys <http://pgp.greatvideo.com/keys/rguerra/>
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: Has RSADSI Lost their mind?
Date: 16 Jul 2000 01:44:50 GMT
Bill Unruh <[EMAIL PROTECTED]> wrote:
>> NTRU, described at http://www.ntru.com/
> Well, described is a bit strong. There is absolutely no description
> However there is a mentionof the patent
> US06081597
Didn't they have a link to their paper from ANTS III on that site
somewhere? or did they redesign the site again?
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: unambiguous polynomial computation and crypto
Date: Sat, 15 Jul 2000 18:45:53 -0700
David A Molnar <[EMAIL PROTECTED]> wrote in message
news:8kqrnv$38u$[EMAIL PROTECTED]...
>
> Last term, my professor brought up the connection between unambiguous
> computation and one-way functions to show that it may not be possible
> to "base cryptography on P vs. NP," because one-way functions exist
> iff P != UP, and UP is unlikely to have complete problems. This
> is also in Papadimitriou _Computational Complexity_, along with
> the usual note that NP-complete problems aren't necessarily hard on
> average.
I hate to sound stupid (you'd think I'd be used to it by now), but what's UP
(Unambiguous Polynomial Computation, obviously, but what's that)?
--
poncho
------------------------------
** 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
******************************
