Cryptography-Digest Digest #645, Volume #11 Thu, 27 Apr 00 12:13:01 EDT
Contents:
Re: new Echelon article ([EMAIL PROTECTED])
Re: sboxes for the bored... ([EMAIL PROTECTED])
Re: U-571 movie (Andrew Carol)
Re: Help: encrypting bit fields (Francois Grieu)
Re: What does XOR Mean???!!! (jan grant)
Re: OAP-L3: Semester 1 / Class #1 All are invited. (Taneli Huuskonen)
Re: OAP-L3: Semester 1 / Class #1 All are invited. (Taneli Huuskonen)
Re: AEES 16 rounds (Runu Knips)
Re: factor large composite ([EMAIL PROTECTED])
Re: Karatsuba threshold (Francois Grieu)
Re: Help: encrypting bit fields (David A. Wagner)
public/private encryption keys and biometrics ([EMAIL PROTECTED])
Re: sboxes for the bored... (Terry Ritter)
Re: papers on stream ciphers (David A. Wagner)
Re: Help: encrypting bit fields (Terry Ritter)
Re: Career Opportunities @ Cloakware ("Trevor L. Jackson, III")
Re: Career Opportunities @ Cloakware ("Trevor L. Jackson, III")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Crossposted-To:
alt.politics.org.cia,alt.politics.org.nsa,alt.journalism.print,alt.journalism.newspapers
Subject: Re: new Echelon article
Reply-To: [EMAIL PROTECTED]
Date: Thu, 27 Apr 2000 13:06:55 GMT
On Mon, 24 Apr 2000 16:13:33 -0600, Jerry Coffin <[EMAIL PROTECTED]>
wrote:
>In article <[EMAIL PROTECTED]>, Publisher@
>6th.Estate.com says...
>
>[ ... ]
>
>> Some things to cogitate on:
>>
>> 1. The U.S. requires that _all_ materials with a strategic defense
>> purpose be second-sourced.
>
>Yes and no -- they require that it be studied and reasoning be given
>if it's not available from at least two sources.
>
>> Because Windows is on so many DoD computers
>> (and every other agency), and on so many computers of companies who
>> supply the DoD, it legitimately would be a product with a strategic
>> defense purpose. But Mr. Gates' company got an exception to the second
>> sourcing rule and there it no second source required for Windows.
>> Curious.
>
>Not particularly -- if you're buying something like tanks or
>submarines, getting more if a single source becomes unavailable is
>quite difficult (e.g. it might take YEARS for another contractor to
>be ready to build a submarine).
>
>By contrast, if Microsoft went bankrupt, or for whatever other reason
>could/would no longer supply Windows, it would be _extremely_ trivial
>for the government to make as many more copies of the disks as they
>saw fit. Obviously this would normally violate copyright laws, but
>most such things can be abrogated in the interest of national defense
>-- e.g. if MS was still in business but declined to sell Windows
>anymore, they'd probably just end up paying a "reasonably royalty
>fee" to MS for each copy they manufactured themselves.
>
>Software would only reasonably fall into the same situation as most
>defense hardware if reproducing it was difficult and/or expensive.
>That's not presently the case, and I don't see any indication that it
>will become the case either. Note that this basically applies to any
>and all software, regardless of the vendor -- MS isn't particularly
>special in this respect.
Good comment but I'm not sure you've considered the whole shebang.
What you say rings valid if you're looking at the replication and not
the manufacturing of it. A tank or submarine is manufactured with
machines; software is manufactured by human intellect and needs to
evolve.
The ones who know it best are the ones who created it and build it.
Under your scenario you'd be able to copy current versions, but what
if someone created a virus to attack current versions and all the
programmers were laid up in bed with, let's say, "space herpes." Who
would know the interaction of the modules better than the developers?
Considering the size of the Redmond campus, I wouldn't wing a guess at
the learning curve or manyears needed to get up to speed on it.
So that's what I'm thinking of. It's not a simple as duplication. And
when you're considering whether a second source is required, I hope
they are considering worst case scenario.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: sboxes for the bored...
Date: Thu, 27 Apr 2000 14:34:58 GMT
Is it pssoble to combine F functions together to make a stronger
non-linear S - Box:
e.g.
Yi = Xi .OR. F(F1,...Fn)
where F(F1...Fn) = F1(K1,Xi+1).OR.F2(K2,Xi+1)...Fn(Kn,Xi+1)
either an OR or � or some other non-linear combination....
How would that work?
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Andrew Carol <[EMAIL PROTECTED]>
Subject: Re: U-571 movie
Date: Thu, 27 Apr 2000 07:45:30 -0700
In article <[EMAIL PROTECTED]>, NFN NMI L.
a.k.a. S.T.L. <[EMAIL PROTECTED]> wrote:
> Teraflop supercomputers are fast, badass computers. They have everything to
> do
> with breaking codes.
His question was related to their use of the term FLOPS. Floating
Point Operations Per Second. The vast bulk of code analysis probably
does not require floating point arithmetic. Ciphers don't deal well
with roundoff.
>
> <<and _everyone_ knew that the Japanese would _never_ attack the US.>>
>
> The Japanese had a history of launching unannounced attacks. Ask the
> Russians.
They did after Pearl Harbor, but their war with Russia was already old
news in the 40's and one time does not make a "history" of it.
--- Andy
------------------------------
From: Francois Grieu <[EMAIL PROTECTED]>
Subject: Re: Help: encrypting bit fields
Date: Thu, 27 Apr 2000 16:52:42 +0200
Runu Knips <[EMAIL PROTECTED]> wrote:
>Paul Rubin wrote:
>> Say I want to simulate a 37-bit codebook cipher. Alternatively, say
>> I want to encrypt an integer range, such as 10-digit decimal integers.
> Can anyone explain to me why he doesn't just use
> (..) any stream cipher - whats the problem ?
A stream cipher allows selective bit manipulation, which is undesirable
in some cases. Also, stream ciphers don't work in decimal.
For small message space (say up to S=64 messages) the best is probably
to use a permutation generated using the key, among the S! possible ones.
Above, an idea is to use a tailor-made Feistel cipher, using a 'known
good' cipher as the building block. For example, assuming one wants
to encipher a 37-bit block using DES
split in two halves L0 (19 bits) and R0 (18 bits)
R1 = R0 XOR low18bits(DES(K,0x2000000000000000 XOR L0))
L1 = L0 XOR low19bits(DES(K,0x4000000000000000 XOR R1))
R2 = R1 XOR low18bits(DES(K,0x6000000000000000 XOR L1))
L2 = L1 XOR low19bits(DES(K,0x8000000000000000 XOR R2))
R3 = R2 XOR low18bits(DES(K,0xA000000000000000 XOR L2))
L3 = L2 XOR low19bits(DES(K,0xC000000000000000 XOR R3))
with result in L3 R3.
This cipher is easily invertible. The constants are to make sure the
cipher can't be used to invert itself (without these and for even bit
sizes, decryption would be swap-encrypt-swap, big problem in a chosen
plaintext attack), and to use different, apparently-independant mappings
at each round. The idea should work fine up to 128 bits (I fear however
the technique does not make all mappings exactly as likely, and it might
be weakness for small message space).
Problem gets worse if the block space size S is not a power of two. If S
can be split into S = L*R with L and R about the same magnitude (as in
100000 = 250*400), we can split the plaintext P by writing
P = L0*R+R0 with L0<L and R0<R
and using
R1 = (R0 + DES(K,0x2000000000000000 XOR L0))%R
L1 = (L0 + DES(K,0x4000000000000000 XOR R1))%L
and so on.
If S is prime or otherwise can't be split evenly [say S=99998=2*49999],
an option is to assign a mapping between one particular plaintext and
one particular ciphertext [say, with a negligible bias for small S, map
plaintext DES(K,1)%S to ciphertext DES(K,2)%S]; this reduces the problem
to finding a mapping between S-1 plaintexts and ciphertexts, which may
be easier, e.g. S-1=99997=277*361.
Francois Grieu
------------------------------
From: jan grant <[EMAIL PROTECTED]>
Subject: Re: What does XOR Mean???!!!
Date: Thu, 27 Apr 2000 14:42:47 GMT
R124c4u2 wrote:
> You're right. This, which is in some sense the complement of xor, will also
> work.
>
> Here is what I should have said in my initial post:
>
> Of all the possible boolean operators available to a computer programmer, xor
> is unique in that: blah, blah, blah.
...and you'd still be wrong.
bool c, p, k, p2;
...
c = p == k;
p2 = c == k;
--
perl -e 's?ck?t??print:perl==pants if $_="Just Another Perl Hacker\n"'
------------------------------
From: [EMAIL PROTECTED] (Taneli Huuskonen)
Crossposted-To: talk.politics.crypto
Subject: Re: OAP-L3: Semester 1 / Class #1 All are invited.
Date: 27 Apr 2000 17:45:00 +0300
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
In <[EMAIL PROTECTED]> Anthony Stephen Szopa
<[EMAIL PROTECTED]> writes:
[...]
>I entertained you when you suggested that you could predict
>subsequent digits from the MixFile process you referred to to
>see where it would lead.
Oh, almost forgot to ask: have you sent me the challenge yet, as we
agreed?
Taneli Huuskonen
=====BEGIN PGP SIGNATURE=====
Version: PGPfreeware 5.0i for non-commercial use
Charset: noconv
iQA/AwUBOQhSWF+t0CYLfLaVEQLnzgCgqQt7XTtkpolMxoPtw7yrkqkDUHkAoOg4
HhUQJBfhu0RVpocN+qiNQvfS
=PCph
=====END PGP SIGNATURE=====
--
I don't | All messages will be PGP signed, | Fight for your right to
speak for | encrypted mail preferred. Keys: | use sealed envelopes.
the Uni. | http://www.helsinki.fi/~huuskone/ | http://www.gilc.org/
------------------------------
From: [EMAIL PROTECTED] (Taneli Huuskonen)
Crossposted-To: talk.politics.crypto
Subject: Re: OAP-L3: Semester 1 / Class #1 All are invited.
Date: 27 Apr 2000 17:39:15 +0300
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
In <[EMAIL PROTECTED]> Anthony Stephen Szopa
<[EMAIL PROTECTED]> writes:
>Taneli Huuskonen wrote:
[...]
>>
>> Usg IIP MixFile1 MixFile2 MixFile3 Digit
>> 1 8 6327491805 5382460791 1352094678 9
>> 2 3 7246301598 6153704298 7801354926 7
>> 3 5 7845069213 4019682573 2184065379 1
>> 4 9 1904735268 4273860915 8670159423 3
>> 5 1 0819374256 6421935087 9710324865 0
>> 6 7 3145682790 8601534279 8523419670 6
>>
[...]
>You obviously don't have a clue what a table is for or what you are
>looking for in this table or what you need to reply to let me know
>that you "get it."
So far, I've made an attempt to keep the discussion civil, even though
I've often been tempted to behave otherwise. However, if you further
insist on turning the discussion into a flamefest, I'll see what I can
contribute in that respect.
I thought you'd devised an algorithm that took the first five columns of
your table as input and produced the digit in the sixth column as
output, and I attempted to do the same. I came up with an algorithm
whose output agreed with your table, and posted some sample results.
I have two questions.
1) Does OAP-L3 Version 5.0 contain a pseudorandom digit generator, each
output digit of which is generated from five data items, corresponding
to the leftmost five columns of your table, and mine as well?
2) If those five columns of my table were used as input to the
pseudorandom digit generator, one row at a time, would it output the
digits in the sixth column, except that the digit in the fifth row
should be 5?
>When I release OAP-L3 Version 4.3 I will make available the paper I
>wrote explaining the fundamentals upon which Version 5.0 will be
>based. This table will be included, of course.
OK, my questions above will be answered then. I'd just like to get
simple yes/no answers to them now.
>Also note that you have misrepresented the random number generator
>when you say the random digit generator in OAP-L3 is not
>cryptologically secure.
No, I didn't. I was careful to distinguish between the pseudorandom
digit generator, which is part of OAP-L3, and the whole of OAP-L3. The
former is definitely insecure. This insecurity may or may not be
completely covered by subsequent processing, probably depending on the
key. I don't know what kind of keys, if any, would result in OAP-L3
being unbreakable by a competent cryptanalyst with ample computing
resources, but I wouldn't be surprised if such keys existed.
Some people have obviously misunderstood the nature of my challenge to
you. However, I haven't done anything deliberate to cause such
misunderstandings; on the contrary, I've occasionally corrected other
posters about it.
[...]
>Your requirements to do this only prove that the entire random number
>generator process IS secure and here is why.
My requirements prove that OAP-L3 is secure against one particular
clueless person who doesn't want to spend more than a few hours probing
it for potential weaknesses, nothing more.
[...]
>You are not in my kill file but I will only reply to honest and
>intelligent posts from you in the future.
My criteria for deciding which postings I follow up are different.
Taneli Huuskonen
=====BEGIN PGP SIGNATURE=====
Version: PGPfreeware 5.0i for non-commercial use
Charset: noconv
iQA/AwUBOQhQ/F+t0CYLfLaVEQLImgCfRTeqmfhDO1+0ee3hXkjJgXjnlEoAnR7B
gAlyZUYRv+sz0wdZi1X4cNfz
=S41S
=====END PGP SIGNATURE=====
--
I don't | All messages will be PGP signed, | Fight for your right to
speak for | encrypted mail preferred. Keys: | use sealed envelopes.
the Uni. | http://www.helsinki.fi/~huuskone/ | http://www.gilc.org/
------------------------------
Date: Thu, 27 Apr 2000 17:04:36 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: AEES 16 rounds
Manuel Pancorbo schrieb:
> <[EMAIL PROTECTED]> escribi� en el mensaje de noticias
> 8e6lle$p3n$[EMAIL PROTECTED]
> > Performance with my IP II,267 Mhz, 128 Mb is 101 Kb/sec.
> A bit slow, isn't it?
But the last time he posted here it was only 64 KB/sec.
So he improved the speed by more than 50% in such a
short time. Cool :)
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: factor large composite
Date: 27 Apr 2000 10:54:58 -0400
In article <[EMAIL PROTECTED]>, Tom St Denis <[EMAIL PROTECTED]> writes:
>
>[EMAIL PROTECTED] wrote:
...
>> comptations (using the number field sieve). Anyone with 64Mb
>> to spare for a week or two might take a look at
>>
>> http://www.lehigh.edu/~bad0/cabal773.html
>>
>> to get a better idea of what breaking RSA keys looks like.
Leaving B. Dodson confused as to what part of "to get a better
idea of what breaking RSA keys looks like" Tom St Denis felt
compelled to refute.
>> This is the first step in a longer-term project ...
...
>They are not factoring RSA keys though, they are factoring numbers of
>special composition (similar to mersenne primes). This hardly
>constitutes factoring RSA numbers with 384 bit factors...
And again, what part of "first step" and "longer-term" is in
dispute? The number is question is (2^773)+1, and it does
indeed have 773-bits, with 773 > 768. It was chosen from
among several candidates for breaking the 768-bit special
number field sieve barrier (if there is one; we previously
factored 10^211-1. That was in between factoring RSA-140
and RSA-155, the latter at 512-bits). There was an extensive
pre-test with ECM, which can indeed be observed as being
recorded on the pages of the Mersenne project (where the number
in question is referred to as P773). We presume that the smallest
prime factor has at least 47-digits, but that doesn't even rule
out the 227-digit composite cofactor having 3 or even 4 prime
factors (although in the latter case ECM would have had a better
likelyhood of success). There's no intention of misleading
anyone into believing that this is a GNFS factoriztion (which is
why the page has "SNFS" in it's title. Sigh.).
I still maintain that anyone, such as the person whose post
I was replying to, under the impression that computers factor
numbers of this difficulty on their own, without much attention
on the part of the operator, might well get a much better feel
for the labor-intensive part of breaking a 768-bit RSA key (not
to mention the 2048-bit RSA key that initiated this thread) from
this current Cabal project. On the main topic that is in dispute
(between cyptosavvy and rsalabs, both on key selection), whether
the matrix computation for completing the factorization of a 768-bit
RSA key will be done in public within 10 years (="longer-term"),
the matrix that results from sieving 2^773+1 provides a nontrivial
test case, perhaps twice as hard as the RSA-155 matrix. A person
spending 2-3 weeks computing could plausibly claim to have their
own personal data included in several of the rows of this new
hardest-ever sparse factoring matrix.
B. Dodson
>Tom
>--
>Want your academic website listed on a free websearch engine? Then
>please check out http://24.42.86.123/search.html, it's entirely free
>and there are no advertisements.
Perhaps I'm confused again, but this appears to me to be
an advertisement. (As well as the above solicitation of
sieving contributions.)
------------------------------
From: Francois Grieu <[EMAIL PROTECTED]>
Subject: Re: Karatsuba threshold
Date: Thu, 27 Apr 2000 17:32:48 +0200
[EMAIL PROTECTED] (Mark Wooding) wrote:
> Scott Contini <[EMAIL PROTECTED]> wrote:
>
>> Moreover, two of the recursive calls are actually squaring
>> operations - so one should have optimized Karatsuba squaring
>> and optimized classical multiply squaring (taking advantage of
>> symmetry).
>
> Err. I thought that Karatsuba-Ofman worked on the identity
>
> (u b + v)(x b + y) == u x b^2 + ((u + v)(x + y) - u x - v y) b + v y
>
> (where b is some convenient value about half the size of each of the
> two numbers being multiplied).
>
> The three multiplications are, then, u x, v y and (u + v)(x + y).
> None of these looks like a squaring to me.
Scott was thinking of squaring with Karatsuba. If we set u=x, v=y,
this translates into 3 squaring of half size: u^2, v^2, (u+v)^2
BTW, Knuth's Karatsuba variant is
(u b + v)(x b + y) == u x b^2 + (u x + v y - (u - v)(x - y)) b + v y
with the advantage that |u-v| has one bit less than u+v,
and the disadvantage that we have cases with the signs.
Francois Grieu
------------------------------
From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: Help: encrypting bit fields
Date: 27 Apr 2000 07:55:56 -0700
In article <8e5qcm$vlc$[EMAIL PROTECTED]>,
Paul Rubin <[EMAIL PROTECTED]> wrote:
> Say I want to encrypt a bit field (37 bits, for example) and get
> back another 37-bit field. E.g. I want to simulate a 37-bit codebook
> cipher.
The only promising idea I've heard is to build
a custom-built Feistel cipher, with F-functions
built out of DES or somesuch. But use lots of
rounds (e.g., at least 8): there are generic
attacks on small-round Feistel ciphers that are
usually of theoretical interest only in
large-block ciphers, but might become a larger
concern for small-block ciphers. I don't know
of any proof that this is as secure as we'd like
to believe, but I suspect it's ok.
You could also try to create a custom-designed
substitution-permutation network, but I suspect
there would be more pitfalls with this approach.
Block cipher design is tricky.
------------------------------
From: [EMAIL PROTECTED]
Subject: public/private encryption keys and biometrics
Date: Thu, 27 Apr 2000 15:29:19 GMT
I need some information. My company is looking for software that
incorporates public/private key encryption with biometrics. Or at least
a company that offers an SDK (software development kit) that will allow
us to mesh the two.
Our primary goal is to substitute biometrics (fingerprint or photo) for
the passphrase when creating a key.
Anyone have any leads? I am sure there must be a company out there that
does.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: sboxes for the bored...
Date: Thu, 27 Apr 2000 15:41:34 GMT
On Thu, 27 Apr 2000 14:34:58 GMT, in <8e9j6g$br$[EMAIL PROTECTED]>, in
sci.crypt [EMAIL PROTECTED] wrote:
>Is it pssoble to combine F functions together to make a stronger
>non-linear S - Box:
>
>e.g.
>
>Yi = Xi .OR. F(F1,...Fn)
>
>where F(F1...Fn) = F1(K1,Xi+1).OR.F2(K2,Xi+1)...Fn(Kn,Xi+1)
>
>either an OR or � or some other non-linear combination....
I assume that F() is a permutation, a math structured subset of the
arbitrary permutation possible in a substitution or s-box. If F() is
not a permutation, it is not clear that F() can make a strong s-box,
which must be a permutation.
Apparently F() is a simplified s-box, not an arbitrary s-box, which
means F() does not have the nonlinearity distribution of a box that
size. That probably means trouble.
I have shown how to combine two arbitrary s-boxes of similar size into
a larger box of twice that size, thus attaining the Boolean function
nonlinearity expected for an arbitrary box of the larger size. See:
http://www.io.com/~ritter/ARTS/MIXNONLI.HTM
Then we just continue the process until we get a block cipher with a
simulated huge block size.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: papers on stream ciphers
Date: 27 Apr 2000 08:03:19 -0700
In article <[EMAIL PROTECTED]>,
Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
> "David A. Wagner" wrote:
> > Of course, the counterargument is that such a feedback mode must now
> > be resistant to chosen-ciphertext attacks, whereas the feedback-less
> > construction needs only to be secure against known-plaintext attacks,
> > which may be easier to achieve. How do we weigh these two opposing
> > considerations?
>
> Chosen-ciphertext doesn't necessarily help (compared to known-plaintext)
> for such systems,
I agree, it doesn't necessarily help, if the cipher has been properly
designed. All I'm saying is that the cipher must be so designed, and
this is just one more failure mode.
Another way to view it is that chosen-ciphertext attacks allow the
adversary to probe the internals of the cipher with chosen values,
and these types of probes may give the attacker considerably more
leeway.
We can take a number of standard stream ciphers that are believed
secure in the feedback-less mode: if they are modified in a too-simple
way to accept ciphertext feedback, attacks become possible.
> and in the standard communications setting [chosen-ciphertext] isn't
> even available (whereas known-plaintext attack is frequently possible).
May I ask why you say chosen-ciphertext isn't available?
I thought in the standard communications setting, we assume the
adversary has control over the network (or, at least, is able to
send forged packets). That sounds to me suspiciously like the
beginnings of a chosen-ciphertext attack -- what am I overlooking?
I agree that if the packets are also MACed in the right way, then
chosen-ciphertext attacks appear to become much harder. Is that
what you were talking about?
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Help: encrypting bit fields
Date: Thu, 27 Apr 2000 15:45:12 GMT
On Thu, 27 Apr 2000 16:52:42 +0200, in
<[EMAIL PROTECTED]>, in sci.crypt
Francois Grieu <[EMAIL PROTECTED]> wrote:
>Runu Knips <[EMAIL PROTECTED]> wrote:
>
>>Paul Rubin wrote:
>>> Say I want to simulate a 37-bit codebook cipher. Alternatively, say
>>> I want to encrypt an integer range, such as 10-digit decimal integers.
>
>> Can anyone explain to me why he doesn't just use
>> (..) any stream cipher - whats the problem ?
>
>A stream cipher allows selective bit manipulation, which is undesirable
>in some cases. Also, stream ciphers don't work in decimal.
Not true. All that is required is a combining function that takes
data and confusion into ciphertext, and an associated function that
takes ciphertext and confusion back into plaintext. A Latin square of
appropriate size and its inverse will do that, and we can key the Ls.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
Date: Thu, 27 Apr 2000 12:04:31 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Career Opportunities @ Cloakware
"John A. Malley" wrote:
> 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."
Not quite. It still executes, so it is far from garbage. Anyone who knows
their way around a core dump will be comfortable with obfuscated code. Most
of a core dump truly is garbage.
There is no sense in which obfuscated code is tamper-proof. Fact is, the
"soft" in software derives from the ease of modification. Worse than jumbo
shrimp, tamper-proof software either isn't software as used in the von Neuman
computer architecture (stored program), or isn't tamper proof. While you can
obliterate all aspects of human readability, you cannot obliterate any aspect
of computer executability without damaging the functionality. Removing
readability is not proof against modification, but merely a form of passive
resistance to modification.
> 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?)
The few word preceding the quote I posted include the verb "design". Now why
would you want to design a technology if you already have a patent pending?
> 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/ )
If its pending it won't be published yet. Only awarded patents get published.
> 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."
Source code "shrouding" goes back at least a couple decades.
>
>
> 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?
------------------------------
Date: Thu, 27 Apr 2000 12:12:43 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Career Opportunities @ Cloakware
"John A. Malley" wrote:
> 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."
"Tamper resistant" is a far more believable claim.
> 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.
I think there's a weakness here though. Given a tool that analyzes source
code to perform behaviorally identical complexification, one could imagine a
similar tool that would rewrite the source code with the same intent of
behavior invariance. Such a simplification tool could produce new code (like
a HLL compilers code generation optimizations), or simply grind away at
reducing extraneous complexity. Presumably no human could perform the
reduction (humans might prefer to rewrite), but a code optimizer probably
could.
How long before the 2600 crowd announces the ability to simplify cloaked
source code? Any predictions out there?
>
>
> It makes spaghetti code out of clear, well designed software.
>
> *Shudder*
This is not patentable. This is the job description for "entry level
programmers". ;-)
> 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
******************************
