Cryptography-Digest Digest #27, Volume #13 Sat, 28 Oct 00 14:13:00 EDT
Contents:
Re: Is OPT the only encryption system that can be proved secure? (Richard Heathfield)
Re: Is OPT the only encryption system that can be proved secure? (Terry Ritter)
Re: ring homomorphic signature and encryption ("John A. Malley")
Re: Is OPT the only encryption system that can be proved secure? (Terry Ritter)
Re: Is OPT the only encryption system that can be proved secure? (SCOTT19U.ZIP_GUY)
Computer Security at the CUNY Graduate Center (MikeAt1140)
----------------------------------------------------------------------------
Date: Sat, 28 Oct 2000 18:06:03 +0100
From: Richard Heathfield <[EMAIL PROTECTED]>
Subject: Re: Is OPT the only encryption system that can be proved secure?
"SCOTT19U.ZIP_GUY" wrote:
>
> [EMAIL PROTECTED] (Richard Heathfield) wrote in
> <[EMAIL PROTECTED]>:
>
> >
> >If you liked your code to work, you too would pay attention to
> >diagnostics. Since you clearly don't care about diagnostics, I must
> >conclude that you aren't fussed whether your code works or not.
> >
>
> Then your making another mistake.
In your opinion only.
> scott18u evolved through
I wouldn't know about scott18u. I've only seen the source for scott19u.
> many hours of testing on my 486 which is dead. I no longer even
Am I to infer that your program killed your machine? It wouldn't
surprise me.
> have all the test code. But I learned years ago testing is the
> way to check ones code to see if it works. Not blindly worrying
> about warnings that get in your way.
Is that how you treat traffic signs too? Honestly, this is too easy -
it's like shooting fish in a barrel.
> >1) <shrug> I bet Get_nBit_Int() works a damn sight faster under Linux
> >than get19() does.
> >2) Performance isn't (or, at least, wasn't) the issue here. You said it
> >was simply not possible to do this in portable C. But I have shown that
> >it is not only possible but trivial.
>
> Actually the issue was wether scott19u could trivially be turned
> into funtional highly portable code. You have some code that replace
> some of it. Granted it may be one of the harder parts (if it works)
> but you have not shown that converting the whole program is protable.
No, I haven't, but I've eliminated the main cause of non-portability,
which is the "need" for DJGPP-specific macros and pragmas. I've also
eliminated the need for bit-fields (which have portability issues) and
your union of p19 with unsigned char (which I didn't closely inspect,
but unions are a frequent cause of non-portability when abused).
Consequently, I'm reasonably sure (although I'll freely admit I haven't
toothcombed the code) that the only portability issues remaining are in
the key management code, which isn't part of the algorithm anyway.
Therefore, I have shown that it should now be relatively trivial to
write a portable version of your algorithm.
> I did have mnay macros that tested while on an individual
> basis but when I but them all together the complier went into never
> never land. I think some interal stack overflowed.
Or it could have been undefined behaviour because of your use of void
main(). Strictly speaking, you can't be sure that it wasn't.
>
> >3) If speed is so crucial to you, why is your program so bloody slow?
>
> scott16u is more optimezied for speed. I have stated many time
> scott19u is dam slow. Even after I made it my son and I use modifed
> scott16u for our encryption purposes. It is slow due to the 19 bit
> word sizes. I used 19 bits since that is max size with this structure
> one could carry a single keyfile on a 3.5" floppy. People thought
> scott16u was to big so I made one bigger. However I must say on my
> K6-III it really flies and as computers are only going to get faster
> with more memory scott21u may not be that far away.
Well, you have half a point here. The performance of your program seems
to degrade linearly with plaintext size (I didn't bother checking for
different key sizes). So in that respect, Moore's Law is on your side -
faster computers will indeed make your program faster. But on the other
hand, other people already have much faster programs than yours (on a 10
Megabyte file, your program took around 100 seconds on a PII-400 running
NT).
> >No, don't do that. These functions belong in C files, not H files. They
> >are source code, not type definitions.
>
> THere are no rules about not having function in include files.
No, you're right. In the same way, there's no rule about wearing your
underwear /underneath/ your jeans. But this is sci.crypt, not a language
newsgroup, so I won't press the point.
> Is this some rule that purists are going to force in as just
> becasue they don't like the current capabilites that they will
> weaken C as they did with octal constant conversions.
Are you trying to make Dennis Ritchie and Doug Gwyn break out in
hysterical laughter?
<snip>
--
Richard Heathfield
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Is OPT the only encryption system that can be proved secure?
Date: Sat, 28 Oct 2000 17:07:32 GMT
On Sat, 28 Oct 2000 11:19:01 +0200, in
<[EMAIL PROTECTED]>, in sci.crypt Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:
>Terry Ritter wrote:
>>
>
>> Mathematical proofs concern models which may not, and probably do not,
>> exist in practice. It is important to keep the distinction in mind.
>
>Even practically possible models may not always apply in
>one's specific applications. So, if a cipher, say, is easily
>crackable under chosen ciphertext attack but practically
>secure with respect to the other possible attacks, then it
>is o.k. if one knows that the vulnerable attack is impossible
>in one's specific environment. If a certain attack needs
>huge amounts of materials processed by a single key and
>one takes care to change key very often or even employ
>variable keys (for blocks) then that attack is irrelevant
>in one's application. Such academic attacks are certainly
>important though for the science in long terms and also
>for the scientists in short terms (because of 'publish
>or peril').
I do of course agree that mathematical models *can* help, but I do not
agree that they *necessarily* help. This discussion of OTP's is one
case in which the mathematical model provides nothing we can rely upon
in practice.
You will recall that I have previously emphasized both the inability
of the mathematical model to quantify the "amount" of randomness
needed, and our inability in practice to measure the generator and
guarantee that it does produce that "amount." In short, we don't know
how much we need, and we don't know how much we have; in fact, we
don't even know what "much" means. That would seem to be
characteristic of a very unhelpful model.
Consequently, we are unable to certify that the physical reality meets
the requirements of the mathematical model. And until we can so
certify, any theoretical results developed from the mathematical model
simply are not appropriate for transfer to reality. The theoretical
security proof cannot be correctly applied to a real system.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: "John A. Malley" <[EMAIL PROTECTED]>
Subject: Re: ring homomorphic signature and encryption
Date: Sat, 28 Oct 2000 10:23:20 -0700
David A Molnar wrote:
>
> Hi,
>
> This may be a shot in the dark, but -- does anyone know of a signature
> scheme which is also a ring homomorphism on, say, Z_N ? an encryption
> scheme?
>
> Straight RSA is a multiplicative homomorphism, which makes it a
> group homomorphism on Z_N^*. This is for both encryption and signatures.
> But it is not an additive homomorphism (indeed, there's a cryptosystem in
> EUROCRYPT '99 based on the assumption that it's not an additive
> homomorphism). I am interested in a signature scheme which is a
> homomorphism for both * and + over Z_N^*.
>
> An encryption scheme with the same properties would be nice, too. The
> closest thing I know is the scheme described in Sander, Yung, and Young's
> "Non-Interactive CryptoComputing for NC1," which is slightly more general
> than a basic group homomorphism but doesn't seem to directly give both +
> and *. Also it's an encryption, not a signature, scheme.
>
> Anyone know of anything like this or care to conjecture something?
An interesting question. Just a few quick thoughts:
I thought Z_p and Z_p^* ARE already homomorphic to each other when p is
a prime.
There is a mapping of the elements of Z_p into Z_p^* that preserves
multiplication in Z_p. This mapping is not injective, but it exists.
There is a mapping of the elements of Z_p^* into Z_p that preserves
multiplication in Z_p^*. This mapping is not surjective, but it exists.
There is no isomorphism (one-to-one and onto mapping preserving
multiplication) between Z_p and Z_p^*
Here's my reasoning:
Let's consider a set F of order p where p is a prime.
The set F is a finite field. F is an abelian group under addition which
is homomorphic to Z_p. All the non-zero elements in the set F, F' = ( F
- {zero element}), form a group under multiplication which is
homomorphic to Z_p^*. The order of Z_p^* is p-1.
A homomorphism is a mapping phi() from one group to another that
preserves multiplication. So for x, y in G mapped to H by f: G -> H,
f(x)*f(y) = f(x*y).
Z_p is already homomorphic to Z_p^* if we use a mapping phi() such that
each element of F - {zero} maps to itself in Z_p^* and the zero element
of Z_p maps to the identity element e in Z_p^*. So two elements of Z_p
map to the same element (the multiplicative identity element e) in
Z_p^*.
Does this mapping preserve multiplication on Z_p in Z_p^*? Yes. For
phi(zero) = e and phi(e) = e, phi(zero)*phi(e) = e*e = e. And phi(zero
* e) = phi(zero) = e. If x and y are not zero, phi(x) = x and phi(y) =
y, thus phi(x)*phi(y) = x*y = z. And phi(x*y) = phi(z) = z.
So I think Z_p is already homomorphic to Z_p^*, it's just not isomorphic
(i.e. a bijective homomorphism.)
If Z_p^* is homomorphic to Z_p then there must be a mapping psi() that
takes all elements of F - {zero} into F while preserving multiplication.
Let's use a mapping psi() such that each element of F - {zero} maps to
itself in Z_p. But there is NO mapping of any element of F - {zero} to
the zero element in F. So this homomorphism is to a subset of Z_p and
not Z_p totally.
Does this preserve multiplication on Z_p^* on Z_p? Yes. For any x, y in
F - {zero}, psi(x) = x, psi(y) = y, and psi(x)*psi(y) = x*y = z. Now
x*y = z on F-{zero}. So, psi(x*y) = psi(z) = z. For any e, x in
F-{zero}, psi(e) = e and psi(x) = x, and psi(e)*psi(x) = e*x = x, and in
F-{zero} we have e*x = x, so psi(e*x) = psi(x) = x.
BUT, did I overlook something? (I always feel that way before I post on
something like this. I did double check it before posting. Ah well,
paraphrasing the Dakota warrior - "today is a good day to learn." :-)
John A. Malley
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Is OPT the only encryption system that can be proved secure?
Date: Sat, 28 Oct 2000 17:45:53 GMT
On Sat, 28 Oct 2000 09:58:24 -0700, in
<[EMAIL PROTECTED]>, in sci.crypt Sundial Services
<[EMAIL PROTECTED]> wrote:
>[...]
>Having said that, however, I must go on to say that OTP is rather an
>exception to that rule, or maybe, an extreme example of it. We can
>prove that, "except for that wild card," OTP is impregnably secure.
I'm sorry, but that is fundamentally wrong: We cannot *prove* any
such thing about any *real* system which simply claims to be an OTP.
We can't *prove* that any generator meets OTP needs, and thus cannot
appeal to results from the OTP theoretical model. It probably is
secure, but there can be no proof.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Is OPT the only encryption system that can be proved secure?
Date: 28 Oct 2000 17:48:07 GMT
[EMAIL PROTECTED] (Richard Heathfield) wrote in
<[EMAIL PROTECTED]>:
>"SCOTT19U.ZIP_GUY" wrote:
>>
>> [EMAIL PROTECTED] (Richard Heathfield) wrote in
>> <[EMAIL PROTECTED]>:
>>
>> >
>> >If you liked your code to work, you too would pay attention to
>> >diagnostics. Since you clearly don't care about diagnostics, I must
>> >conclude that you aren't fussed whether your code works or not.
>> >
>>
>> Then your making another mistake.
>
>In your opinion only.
I am not sure about the only.
>
>
>> scott18u evolved through
>
>I wouldn't know about scott18u. I've only seen the source for scott19u.
>
I could have sworn on a stack of bibles that I said soctt16u
at least that is what I see when I wrote it.
>
>> many hours of testing on my 486 which is dead. I no longer even
>
>Am I to infer that your program killed your machine? It wouldn't
>surprise me.
>
No it got old and I gave it away for free to a needy family
them I bought my k6-III. The 486 had gone through a couple of
hard drives I did work the poor sucker pretty hard though.
>
>> have all the test code. But I learned years ago testing is the
>> way to check ones code to see if it works. Not blindly worrying
>> about warnings that get in your way.
>
>Is that how you treat traffic signs too? Honestly, this is too easy -
>it's like shooting fish in a barrel.
What kind of fish blow fish or what.
>
>
>> >1) <shrug> I bet Get_nBit_Int() works a damn sight faster under Linux
>> >than get19() does.
>> >2) Performance isn't (or, at least, wasn't) the issue here. You said it
>> >was simply not possible to do this in portable C. But I have shown that
>> >it is not only possible but trivial.
>>
>> Actually the issue was wether scott19u could trivially be turned
>> into funtional highly portable code. You have some code that replace
>> some of it. Granted it may be one of the harder parts (if it works)
>> but you have not shown that converting the whole program is protable.
>
>No, I haven't, but I've eliminated the main cause of non-portability,
>which is the "need" for DJGPP-specific macros and pragmas. I've also
>eliminated the need for bit-fields (which have portability issues) and
>your union of p19 with unsigned char (which I didn't closely inspect,
>but unions are a frequent cause of non-portability when abused).
>Consequently, I'm reasonably sure (although I'll freely admit I haven't
>toothcombed the code) that the only portability issues remaining are in
>the key management code, which isn't part of the algorithm anyway.
>
>Therefore, I have shown that it should now be relatively trivial to
>write a portable version of your algorithm.
>
The point is its not done till the fat lady sings. What I mean
the least 10% of doing anything in software take 90% of the time
or have you heard that before.
UNions are a nice thing becasue it allows you to reuse memory the
way one wonts to with out doing cinversions. It basically is for free
but it would not sureprise my if C code purists drop this feature too.
>
>> I did have mnay macros that tested while on an individual
>> basis but when I but them all together the complier went into never
>> never land. I think some interal stack overflowed.
>
>Or it could have been undefined behaviour because of your use of void
>main(). Strictly speaking, you can't be sure that it wasn't.
>
I have seen comments affect the running of code in old
Fortan compliers. Almost anything is possible, Mayve dropping void
might make it fail. Who knows.
>
>>
>> >3) If speed is so crucial to you, why is your program so bloody slow?
>>
>> scott16u is more optimezied for speed. I have stated many time
>> scott19u is dam slow. Even after I made it my son and I use modifed
>> scott16u for our encryption purposes. It is slow due to the 19 bit
>> word sizes. I used 19 bits since that is max size with this structure
>> one could carry a single keyfile on a 3.5" floppy. People thought
>> scott16u was to big so I made one bigger. However I must say on my
>> K6-III it really flies and as computers are only going to get faster
>> with more memory scott21u may not be that far away.
>
>Well, you have half a point here. The performance of your program seems
>to degrade linearly with plaintext size (I didn't bother checking for
>different key sizes). So in that respect, Moore's Law is on your side -
>faster computers will indeed make your program faster. But on the other
>hand, other people already have much faster programs than yours (on a 10
>Megabyte file, your program took around 100 seconds on a PII-400 running
>NT).
The program is basically indepentend of key size. You can use
a long file or a short file. I know its slow. Like I said if you want
speed try scott16u. Its much faster. They are exactly the saem except
one use a 16bit S-table and the other a 19bit table. The only changes
are that to make 19 work instead of the easier 16 which 2 nicely 2 bytes.
the rotate is about the othe only change I used 8 bits, On scott16u
again nicely one byte. In scott19u I thought about useing 8 bits for
the rotation then decided what the hell make it 9 bits. since I already
had 19 bit fields why not go all the way thats what computers for.
>
>> >No, don't do that. These functions belong in C files, not H files. They
>> >are source code, not type definitions.
>>
>> THere are no rules about not having function in include files.
>
>No, you're right. In the same way, there's no rule about wearing your
>underwear /underneath/ your jeans. But this is sci.crypt, not a language
>newsgroup, so I won't press the point.
You mean I won a point. I'm surprised.
>
>> Is this some rule that purists are going to force in as just
>> becasue they don't like the current capabilites that they will
>> weaken C as they did with octal constant conversions.
>
>Are you trying to make Dennis Ritchie and Doug Gwyn break out in
>hysterical laughter?
Laughter is good medicenin unless they have a lung condition,
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
http://members.xoom.com/ecil/index.htm
Scott LATEST UPDATED source for scott*u.zip
http://radiusnet.net/crypto/ then look for
sub directory scott after pressing CRYPTO
Scott famous Compression Page
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
------------------------------
From: [EMAIL PROTECTED] (MikeAt1140)
Subject: Computer Security at the CUNY Graduate Center
Date: 28 Oct 2000 18:08:26 GMT
The course below may be of interest to doctoral students in the NYC
area.
http://web.gc.cuny.edu/Computerscience/Spring2001.htm
Ph.D. Program in Computer Science
Spring 2001
CSc 81200������ Topics in Computer Security:� How to Hack into a Computer
CODE:� [40494]������� and How to Prevent Hacking.
������������������������ Tuesdays, 11:45 a.m. - 1:45 p.m., 3 credits, Professor
Robert Haralick
�������������������� Room TBA
This seminar and hands-on lab course first discusses the ways in which a hacker
cases a target computer running Windows NT or Linux to gain information on its
configuration and vulnerabilities. Then we discuss the ways in which the hacker
can gain privileged access using the information on vulnerabilities the hacker
has gathered.� Parallel to this discussion will be the ways in which various
system and network services can be configured on the target computer system to
deny the hacker's access into the target computer.�
Each student will complete a set of lab exercises to configure a target system
and hack into it. Some familiarity with operating system administration will be
needed as pre-requisite. No audits will be permitted in this course. The text
will be Hacking Exposed by Stuart McClure, Joel Scambray, and George Kurtz
published by Osborne/McGraw Hill.
Ethics Statement
Associated with the course is a set of computers in the Computer Science�
laboratory on which each student will be able to act as system's manager to
specially configure the system to allow or disallow certain services that are
related to how hackers gain uninvited entry.� Hacking into acomputer as an
uninvited guest is equivalent to walking into someone's house uninvited. It is
something that is illegal and something a professional person does not do, even
if the hacking changes nothing in the computer system.� The only computers on
which the exercises of this course can be done are those designated in the
Computer Science laboratory on the written handout sheet given at the beginning
of the course. The techniques and methods discussed in this course for hacking
must not be used on any other computers at CUNY or any other location. Each
student enrolled in the course must sign an ethics statement promising not to
engage in any hacking activities targeting machines outside those specifically
designated in the class.
************************************************************************�
�������������������
�� ����������������������������
Professor Michael Anshel
Department of Computer Sciences R8/206
The City College of New York
New York,New York 10031
------------------------------
** 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
******************************
