Cryptography-Digest Digest #642, Volume #11 Thu, 27 Apr 00 01:13:00 EDT
Contents:
Re: Secret splitting for kids' treasure hunt (Andru Luvisi)
Re: Requested: update on aes contest (stanislav shalunov)
"No adjacent image" hash assumption? (David A Molnar)
Re: Career Opportunities @ Cloakware ("John A. Malley")
Re: Career Opportunities @ Cloakware (David A Molnar)
Re: Career Opportunities @ Cloakware ("John A. Malley")
Re: OAP-L3: What is the period of the generator? (Anthony Stephen Szopa)
Re: OAP-L3: Semester 1 / Class #1 All are invited. (Anthony Stephen Szopa)
Re: OAP-L3: Semester 1 / Class #1 All are invited. (Anthony Stephen Szopa)
Re: Career Opportunities @ Cloakware ("John A. Malley")
----------------------------------------------------------------------------
From: Andru Luvisi <[EMAIL PROTECTED]>
Subject: Re: Secret splitting for kids' treasure hunt
Date: 26 Apr 2000 19:27:51 -0700
[EMAIL PROTECTED] (Stefan Schlott) writes:
[snip]
> A year ago, I used an optical secret sharing scheme to split a treasure
> map into several parts. At first, none of the kids could imagine what
> to do with those funny transparencies showing a lot of black rectangles.
> But when they put them all together... (though proper positioning
> was more difficult than I had thought).
>
> Stefan.
Could I trouble you to explain more about how this worked?
Andru
--
==========================================================================
| Andru Luvisi | http://libweb.sonoma.edu/ |
| Programmer/Analyst | Library Resources Online |
| Ruben Salazar Library |-----------------------------------------|
| Sonoma State University | http://www.belleprovence.com/ |
| [EMAIL PROTECTED] | Textile imports from Provence, France |
==========================================================================
------------------------------
Subject: Re: Requested: update on aes contest
From: stanislav shalunov <[EMAIL PROTECTED]>
Date: Thu, 27 Apr 2000 02:27:31 GMT
Jerry Coffin <[EMAIL PROTECTED]> writes:
> Assuming you're talking about something like multiple layers of
> firewalls/proxy servers (and not multiples running in parallel) then
> yes, the same general reasoning applies.
No, I'm talking about multiple parallel points of entry.
An analogue of multiple layers of firewalls would be cipher cascading,
which none of us has even mentioned before.
> Assume for the moment that NIST decided all five finalists were AES
> ciphers. Further assume that you choose exactly one of those for
> your use.
I *cannot*! My supplier of services today tells me that they have two
ways to accept this piece of data: in cleartext or CBC-Blowfish encrypted.
In this case, I'm happy because we already trust Blowfish in other places.
But if they were using DES, we'd probably have to trust DES, too.
But let's assume just for a second--for the sake of *your*
argument--that I can do it.
> Assume still further that ALL the civilian AND government
> cryptanalysts decide to attack that cipher to the exclusion of the
> other four.
>
> This gives you essentially the worst case scenario.
No and no. Worst case scenario would be: Civilian cryptoanalysts
don't even look at the cipher I use (for example, because they think
it has theoretically boring design), and government cryptoanalysts are
only interested in it alone (for example, because I happen to share my
choice of cipher with somebody very important for them).
When my cipher is broken, I know nothing about it and continue to
happily use it and encrypt new secret data with it.
Notice that we both have silently accepted a paradigm of
cipher-breaking that implies application of certain finite expendable
resource to a particular problem. While this model might be good for
goverment payroll employees, it's likely flawed as far as civilian
analysts are concerned: It's likely that it requires some insight to
break a cipher. The probability of such insight isn't linearly
dependent on time spent studying the problem. Initially it's likely
higher and after certain significant time spent it likely decreases.
If this model has truth to it, it's an additional reason why one of
multiple targets is easier to hit than a single target.
--
stanislav shalunov | Speaking only for myself.
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: "No adjacent image" hash assumption?
Date: 27 Apr 2000 02:10:22 GMT
Hi,
I was thinking about what might be useful to assume from a hash function.
"No adjacent image" assumptions :
Given h : {0,1}^* ---> {0,1}^k , it is infeasible to
a) find two strings x and y such that abs( h(x) - h(y) ) = 1,
b) given a value h(x), find a y such that abs( h(x) - h(y) ) = 1
It seems you could create a hash function which might satisfy this by
taking the output of SHA-1 and multiplying it by 2. Then you'd need to
worry about collisions being introduced that way, though.
why would you care about this? I think that the "adjacency" may be an
example of an "evasive" relation -- that is, something you wouldn't expect
to find easily in the output of a truly random hash function. So I'm
wondering if you can create a cryptosystem which exploits this fact for
efficiency. What I had in mind was a signature scheme which accepts if
the hash of the message H(m) is either the "right" value or within 1 of
the "right value."
Does anyone know if / where this kind of assumption is used elsewhere?
Thanks,
-David
------------------------------
From: "John A. Malley" <[EMAIL PROTECTED]>
Subject: Re: Career Opportunities @ Cloakware
Date: Wed, 26 Apr 2000 19:34:39 -0700
I conjecture the product works much like a java bytecode obfuscator but
for other target languages (such as C and C++)
>From their web site:
"Is Cloakware Technology a type of encryption?
Cloakware Technology should not be confused with encryption.
Encryption
is applied to data whereas Cloakware Technology is applied to
software.
Cloakware's encoding is a one-step, one-way translation. The software
program still runs when cloaked, but cannot be "uncloaked". If
comparisons must be made, then our technology is more similar to a
one-way hash function than cryptography - there is no equivalent to
encryption and decryption."
So it's like Mocha for Java. An obfuscator replaces references and
names in the original code with nonsense variable names or symbols.
When decompiled, the result is "garbage" that's in theory useless to the
"Reverse Engineer." In fact they are advertising for a compiler
designer to implement this. (Which sounds odd on the surface since they
claim they already patented it?)
I ran queries on the IBM Patent Server and failed to find any patents
for Cloakware. I checked European and International Patents as well as
US Patents. ( see http://patent.womplex.ibm.com/ )
I'd like to see what claims they make in their patent on an obfuscator.
Freeware java bytecode obfuscators appeared two or more years ago in the
public domain - doing the things they claim as core technology. And
name-mangling for linking's been around a long time - a related
"technology."
John A. Malley
[EMAIL PROTECTED]
"Trevor L. Jackson, III" wrote:
>
> Marlies Vincken wrote:
>
> > Cloakware Corporation
>
> ...
>
> > "our revolutionary, patent-pending tamper-proof software technology"
>
> ...
>
> Would you care to explain this apparent silliness?
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: Career Opportunities @ Cloakware
Date: 27 Apr 2000 02:48:09 GMT
John A. Malley <[EMAIL PROTECTED]> wrote:
> "Reverse Engineer." In fact they are advertising for a compiler
> designer to implement this. (Which sounds odd on the surface since they
> claim they already patented it?)
Maybe it doesn't run fast enough for their prospective
customers?
> I ran queries on the IBM Patent Server and failed to find any patents
> for Cloakware. I checked European and International Patents as well as
> US Patents. ( see http://patent.womplex.ibm.com/ )
Did you check under the names of the people listed on their "who's
Cloakware?" page?
> I'd like to see what claims they make in their patent on an obfuscator.
> Freeware java bytecode obfuscators appeared two or more years ago in the
> public domain - doing the things they claim as core technology. And
> name-mangling for linking's been around a long time - a related
> "technology."
Yup. I've got a paper in my hands right now which sounds a lot like this
code shrouding. It's "A Tentative Approach To
Constructing Tamper-Resistant Software" by Mambo, Murayama, and E. Okamoto
from the 1997 New Security Paradigms Workshop. It more or less suggests
doing what they're doing. Probably the details are different enough,
though.
Thanks,
-David
------------------------------
From: "John A. Malley" <[EMAIL PROTECTED]>
Subject: Re: Career Opportunities @ Cloakware
Date: Wed, 26 Apr 2000 20:59:08 -0700
"John A. Malley" wrote:
>
> So it's like Mocha for Java. An obfuscator replaces references and
> names in the original code with nonsense variable names or symbols.
Oops. Mocha is the decompiler. The obfuscator is Crema. Both written by
Hanpeter Van Vliet, who died a few years ago from a brain tumor, shortly
after he finished Crema. Borland's JBuilder Version 2.0 is dedicated to
his memory and pioneering work in Java tools.
John A. Malley
[EMAIL PROTECTED]
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: OAP-L3: What is the period of the generator?
Date: Wed, 26 Apr 2000 21:55:34 -0700
Xcott Craver wrote:
>
> Tom St Denis <[EMAIL PROTECTED]> wrote:
> >
> >I may be a bit slow...So what is the period? Why are you using 0-9?
> >Will it work in under a kb of ram?
>
> As hard as it may be to get explicit details or pseudocode
> for Anthony's algorithm, I think the question of his generator's
> period is very basic, very simple, very fair.
>
> Anthony, you should know the period of your pseudo-random
> number generator. This is not an iron-clad indicator of
> security, but something people must know in order to assess it.
> It is also a very basic question asked of generators. I think
> it is reasonable to ask you to please provide this one bit of
> information. No, it isn't in the help files.
>
> Further, if you can't compute the period of your generator,
> then arguably you don't know enough about it, or of the underlying
> mathematics, to make definite and authoritative statements about
> its security. Providing us with at least this much, perhaps
> with proof, would greatly bolster confidence in your algorithm.
>
> Could you please, please, please, please tell us the period
> of your pseudo-random number generator?
>
> -Scott
>
> </NICE>
In order to answer your question we must determine what you are
referring to when you say: pseudo random number generator.
If you are referring to the random digit stream that is generated
directly from the three MixFiles, with each MixFile having 3,628,800
ten-digit permutations of the digits 0 - 9, with an offset of zero
and an initial rotation of zero, in other words, from the very first
possible random digit generated, then I would answer that under the
current implementation, you can generate 79 trillion (79E12) random
digits.
Then by resetting all counters and then by starting with an offset
of 1, you can generate another different 79 trillion random digits.
And finally, if you reset all counters and begin with an offset of 2,
you can generate another different 79 trillion random digits.
This implementation stops generating random digits when you have
generated all possible random digits for a given initial offset as
stated above and displays a message in the window that if you need
more random digits then you will have to use different MixFiles.
Now, if you like, you could say you have essentially an unlimited
period provided you keep changing the MixFiles after you have
generated all 237 trillion random digits from a given set of three
MixFiles.
You should be able to change just one of these three MixFiles and
generate a completely different set of random digits.
Basically, you must be precise in the way you form your question.
But I think I have answered your question under all circumstances.
Now, for your own information, as I have posted in the past,
Version 5.0 will greatly increase the output of the random digit
generator.
As found at http://www.ciphile.com here is a brief reprint of what
you can expect in the near future:
With only 2920 data bytes you will be able to generate 9.2E15 random
numbers from 0 - 255 with a security level equivalent to 2000 bits;
or with only 4600 data bytes you will be able to generate 2.3E17
random numbers from 0 - 255 with a security level equivalent to
10,000 bits;
or with only 1,271,000 data bytes (fits on one floppy) you will be
able to generate 1.3E36 random numbers from 0 - 255 with a security
level equivalent to 100,000 bits.
or more AND more.
These random numbers are then used to logically XOR original data
files thus encrypting them.
The first example has a ratio of random numbers output to stored
bytes of data of 3.15E12.
The second example has a ratio of random numbers output to stored
bytes of data of 5E13.
The third example has a ratio of random numbers output to stored
bytes of data of 1E30.
And again, you can continue to generate as many random digits as you
like by simply changing the data files similar to the description
above.
You see, the real problem with answering this question is because
OAP-L3 does not use any mathematical equations in the random digit
generator like other random digit generators. It relies on byte
manipulation, and the unique referential access of the resulting
permutations sequences to generate random digits.
A simplified analogy is to ask yourself how many sequences of the
cards can you generate from shuffling a deck of playing cards.
The answer is 52! (factorial) possible.
I use three decks of cards with each deck containing 3,628,800
unique "cards" or permutations.
Therefore each deck can assume 3,628,800! unique sequences and the
set of three MixFiles can assume approximately (3,628,800!)^3 unique
sequences.
Do you think you will be needing any more random digits than this in
the near future?
I hope this helps you, your peers, and your bosses. My compliments.
And by the way, does anyone know the penalty for filing a patent
application claiming that you are the inventor when in fact you are
not the inventor?
I also wonder what would be the reaction of a CEO if he or she ever
found out that one of their employees claimed to have invented
something of use for the company when in fact they did not?
I am also looking to license all commercial and business rights to
OAP-L3. I hope to retain the for-personal-use-only rights exclusive
of the commercial and business rights.
Why don't you just ask without implying some fault on my part if I do
not give you the answers you seek.
If you ask me an intelligent question I may reply. But I am
increasingly losing my patience with those who have not adequately
read the Help Files and gotten the software and learned by doing.
In fact, if you need further answers I am available for fee based
consulting only regarding OAP-L3. You have picked my brain enough
for free and taken up much of my precious time.
Read the Help Files and get the software and evaluate it. No more BS
about the documentation. If you don't get it, I'm sorry.
Have your bosses drop me a line if they are interested.
I have two patents pending on OAP-L3: the first one for Version 4.1,
and now the one detailing the fundamental improvements to be
implemented in Version 5.0 along with its implications.
Put all this in your pipes and smoke it.
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: OAP-L3: Semester 1 / Class #1 All are invited.
Date: Wed, 26 Apr 2000 21:59:16 -0700
Xcott Craver wrote:
>
> Tom St Denis <[EMAIL PROTECTED]> wrote:
> >
> >What if the user doesn't follow your rules? It's really simple to screw
> >it up then since the entire security is conjectured to be on the seed.
> >And don't tell me "the user is just plain stupid" because it's human
> >nature to cheat lie and take the easy way.
>
> This is the dancing pigs principle. Any sufficiently restrictive
> security requirement, if it can be circumvented, will be
> circumvented.
>
> And you can't blame the user for not strictly following the
> instructions if the instructions are asinine. Asking,
> for instance, a user to stop typing and shake a can of beans
> in order to operate a piece of software is just that kind of
> instruction. Mr. Szopa is apparently not aware of the speed
> of computers nowadays, if he believes that pausing to perform
> some calculation by hand is a reasonable request of a user.
> Generating a key by this method takes HUNDREDS OF MILLIONS,
> maybe BILLIONS OF MICROSECONDS!!
>
> Perhaps if Mr. Szopa's web browser required him to stand up
> and perform 10 jumping jacks every time he clicks 30 links
> or so, he would rethink his system.
>
> >Why do you rely on unorthodox numbers? Like it has 87 billion possible
> >seeds, and 259,200 arrays, and they are permutations of 0-9... Have you
> >taken one class in comp sci or cryptography? BTW with 87 billion
> >possible seeds thats about 2^70.5, so if thats your key size (I may have
> >misinterpreted this) it's kinda small doncha think?
>
> Wait, what? What? 87 billion is about 2^36.
>
> In any case, this is a common theme in crypto snake-oil:
> a cipher designer unaware of what we mean by "large" or "fast"
> or "efficient." A "large" keyspace is not billions. It used
> to be billions of billions, and is now billions of billions
> of billions. A "fast" system is fast on the order of computer
> speeds, not on the order of human card-shuffling speeds.
> An "efficient" system doesn't achieve the security of comparable
> systems with huge keys or huge amounts of time. This is not
> just an efficiency issue but a security one: each extra bit
> of key or operation should massively improve the security,
> or the operations are suspect.
>
> Bob Knauer, who designed an OTP-like system using music CDs
> as keys, went on the principle that the number of music CDs
> at the record store is "enormous." Depending on the record
> store, you may be looking at a 20-bit key. (He also wins, by
> the way, the award for the most insane and time-consuming key
> generation method. Sorry Anthony!) This was simply someone
> who at the time was thinking on a different scale in terms
> of keysize, cost, time, and difficulty of attacks.
>
> -S
Leave this thread and good riddance. You have not claimed to have read
the Help Files or gotten the software or used the software or talked to
anyone who has.
Your opinions are worthless.
Walk on, waving your hands and trying to attract someone else's
attention. Maybe you will get mugged.
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: OAP-L3: Semester 1 / Class #1 All are invited.
Date: Wed, 26 Apr 2000 22:02:13 -0700
Joseph Ashwood wrote:
>
> On the contrary it actually is a matter of historical record
> that much of the problem with most secured communications is
> actually the user. It was actually published that most new
> users have problems with PGP, generally they do not properly
> recognise when their e-mail is and is not encrypted.
> Joe
>
> "Anthony Stephen Szopa" <[EMAIL PROTECTED]> wrote in
> message news:[EMAIL PROTECTED]...
> > "David Formosa (aka ? the Platypus)" wrote:
> > >
> > > On Mon, 24 Apr 2000 20:51:39 -0700, Anthony Stephen
> Szopa
> > > <[EMAIL PROTECTED]> wrote:
> > > >"David Formosa (aka ? the Platypus)" wrote:
> > >
> > > [...]
> > >
> > > >> Isn't this a rather big assumtion? When cyphers are
> used in the field
> > > >> stupid things happen to them, for example the engma
> cypher was
> > > >> weekened substatualy by poor procedures regarding its
> use.
> > >
> > > >If you say so.
> > >
> > > If I say so? Its a mattor of historical record.
> > >
> > > --
> > > Please excuse my spelling as I suffer from agraphia. See
> > > http://dformosa.zeta.org.au/~dformosa/Spelling.html to
> find out more.
> > > Interested in drawing platypie for money? Email me.
> >
> > Another drowning man clutching at a straw.
> >
> > Why don't you recite a Mother Goose nursery rhyme?
> >
> > Then you can stand tall and say, "Well, she wrote them!"
> >
> > So, you have recited an historical point that no one dare
> refute.
> >
> > You have made no ground regarding OAP-L3.
> >
> > Well, you sure got us on this one.
> >
> > Golly gee.
> >
> > I have addressed this point recently.
> >
> > If you do not follow the manufacturer's instructions, or
> don't
> > follow the state driver's handbook you will most likely
> crash
> > your car.
> >
> > If you don't follow the recipe your cake will fall.
> >
> > So what?
> >
> > What contribution have you made to this news group?
> >
> > You should join, along with many others in this news
> group, the
> > alt.rant.misc news group.
Push this button: NO REPLY.
------------------------------
From: "John A. Malley" <[EMAIL PROTECTED]>
Subject: Re: Career Opportunities @ Cloakware
Date: Wed, 26 Apr 2000 22:09:06 -0700
David A Molnar wrote:
>
>
> Did you check under the names of the people listed on their "who's
> Cloakware?" page?
>
Great idea, and I just did so.
The technology Cloakware references appears to originate at Northern
Telecom, Limited, in Canada.
See Patent Number US5748741: Encoding technique for software and
hardware. Issued May 5, 1998, filed March 7, 1996. Awarded to Northern
Telecom.
Who's on that patent? Harold Johnson, same name as the VP of Engineering
at Cloakware. And Yuan Xiang Gu, the same name as the VP of Software
Operations at Cloakware. Both are ex-employees of Northern Telecom.
The patent claims do not clearly map to obfuscation as done by Java
bytecode obfuscators. Their process takes the original program and its
control flow and transforms it into a new program with complex,
interconnected and interlocked control flow that is behaviorally
equivalent to the original program. However, the complex new interlocks
make it difficult to modify the program to do new things beyond its
original behaviors. This is the goal and meaning of "tamper
resistant." Per this patent, a program is "effectively immutable if its
nature is such that performing any such behaviorally small, but
non-superficial, recipient-useful change from the design is exceedingly
difficult--difficult enough to discourage even a very determined
recipient." So the "Reverse Engineer" can't figure out what connects to
where and thus can't change or reuse the decompiled code in other
projects.
It makes spaghetti code out of clear, well designed software.
*Shudder*
What's not clear from the Cloakware web site is the intellectual
relationship relationship with Northern Telecom.
Does Cloakware exclusively or non-exclusively license this patent or do
they own it outright?
John A. Malley
[EMAIL PROTECTED]
------------------------------
** 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
******************************
