Cryptography-Digest Digest #648, Volume #11 Thu, 27 Apr 00 18:13:01 EDT
Contents:
Re: The Illusion of Security (Diet NSA)
Re: Looking for a *simple* C Twofish source ([EMAIL PROTECTED])
Re: The Illusion of Security (Diet NSA)
Re: Career Opportunities @ Cloakware ("Trevor L. Jackson, III")
Some details about Cloakware (was Re: Career Opportunities @ Cloakware) (Stanley
Chow)
Re: OAP-L3: Semester 1 / Class #1 All are invited. (Tim Tyler)
Re: The Illusion of Security (Diet NSA)
Re: Secret splitting for kids' treasure hunt (Stefan Schlott)
Re: What came of it? (Arthur Dardia)
Re: The Illusion of Security (Diet NSA)
Re: new Echelon article ("Douglas A. Gwyn")
Re: papers on stream ciphers ("Douglas A. Gwyn")
Re: papers on stream ciphers (David A. Wagner)
----------------------------------------------------------------------------
Subject: Re: The Illusion of Security
From: Diet NSA <[EMAIL PROTECTED]>
Date: Thu, 27 Apr 2000 13:15:14 -0700
In article <[EMAIL PROTECTED]>, Tom St Denis
<[EMAIL PROTECTED]> wrote:
>Take factoring for example. Been worked on for 1000s of years,
and we
>still can't factor as fast as one would want to. Like nobody
will
>really find the factors for [snip]
>before I am long since dead. So there are problems that are
just plain
>hard.
>
Actually, there is no public proof that factoring is hard.
Anyways, the problem of factoring in polynomial time has already
been solved theoretically by Peter Shor. His solution, a famous
quantum factorization algorithm, might be implemented during your
lifetime in a large & robust enough way to be relevant for
crypto.
" V hfdt afogx nfvw ufo axb (o)(o) " - Gtnjv
====================================================
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Looking for a *simple* C Twofish source
Date: Thu, 27 Apr 2000 20:07:41 GMT
My case is not at all exotic.
I wish I could use GNU or any other fancy tool but I can't. There are
a lot of microcontrollers out there with very basic C compilers, which
often do not even claim to be ANSI compliant.
- Pointers cause trouble.
- If I cannot define two dimensional arrays, I can split those into two
one-dimensional arrays.
- I cannot afford hundreds of precious RAM bytes for lookup tables. I
can solve that by calling a table entry calculation whenever I need it.
- Complex arithmetic expressions will have some compilers complain or
even produce incorrect code. I can cut those into shorter expressions.
Following Frog's suggestion I've started doing all that on brian
gladman's code, in an effort to make it compile. After about five
hours of simplification I am probably over most of the trouble, but so
much RAM is lost for the compiler (which used it for its own needs) I
have run out of space. It takes a lot of temporary variables to
perform long integer arithmetic. And since brian's implementation was
intended for performance evaluation of AES candidates, I suspect I am
riding the wrong horse here. I don't mind if a block encryption takes
me 50ms - I couldn't care less.
I see your point about Twofish being an engineer's encryption
algorithm, but thousands of programmers will need to integrate it into
their systems at some point, wouldn't they ? whether it's an
engineer's encryption or a marine biologist's encryption, I think it
should come with a pseudo-code listing.
-Al.
In article <8e577t$6v9$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> Hello,
>
> I'll be happy to hear from anyone who knows of a
> freely available, simple, minimal C
> implementation of Twofish.
>
> By simple I mean: not using pointers, or long and
> complex one-line arithmetic expressions. I am
> trying to make it work on a limited and sometimes
> buggy embedded C compiler.
>
> It does not have to be optimized for anything.
>
> Thank you,
> -Al.
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Subject: Re: The Illusion of Security
From: Diet NSA <[EMAIL PROTECTED]>
Date: Thu, 27 Apr 2000 13:28:05 -0700
In article <[EMAIL PROTECTED]>, Mike Kent <[EMAIL PROTECTED]>
wrote:
>Hmm, I think we can, we just don't yet. When some bright person
>proves P != NP and we see NP-hard crypto, I think it will be
>fair
>to say this is strong, really.
>
>
No one knows if P != NP can even be proven, so "when some bright
person proves P != NP" may be never. Even if it were proven I
don't see how such a proof would automatically lead to NP-hard
crypto. (Note that all cryptosytems based on the knapsack
problem, which is an NP-complete problem, have been shown to be
insecure).
" V hfdt afogx nfvw ufo axb (o)(o) " - Gtnjv
====================================================
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
Date: Thu, 27 Apr 2000 16:39:59 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Career Opportunities @ Cloakware
Eric Lee Green wrote:
> "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?
>
> Once upon a time, I ran across a copy-protected software program that
> encrypted itself multiple times. You'd unencrypt it with one key (setting your
> break point in the debugger to the code right after the first unencryption
> routine, of course), and the result was... yet MORE gibberish.
>
> I think I ended up digging through 24 layers of this stuff, then there was the
> code that checked checksums to look for modifications, then ....
>
> Do note that I was doing all of this on a legally-purchased copy of the
> product, and that this occurred before software vendors invented the notion of
> "shrink wrap licensing" and "I Agree" boxes. (i.e., many years ago!). If
> people were doing this in the early 80's, it's unclear that there's new art in
> any similar obfuscation mechanisms....
>
> --
> Eric Lee Green [EMAIL PROTECTED]
> Software Engineer Visit our Web page:
> Enhanced Software Technologies, Inc. http://www.estinc.com/
> (602) 470-1115 voice (602) 470-1116 fax
------------------------------
From: Stanley Chow <[EMAIL PROTECTED]>
Subject: Some details about Cloakware (was Re: Career Opportunities @ Cloakware)
Date: Thu, 27 Apr 2000 20:38:36 GMT
This is a multi-part message in MIME format.
==============F883022655BD449E7CC0B431
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
It seems our job posting has generated a bunch of questions. This
is an attempt to answer some of them.
To start with, I (Stanley Chow) am the VP of Engineering of Cloakware
and one of the names in US patent 5748741. I will gather the questions
from this thread and try to answer them. Since we were not planning
to go public quite so soon, many answers will leave you dangling. Our
first public appearance is a 5-minute talk at the IEEE Symposium in
Oakland in the middle of May.
If anyone wants to get more information, please contact:
[EMAIL PROTECTED]
(If you let them sense big dollars, then it will be easy to sign
the NDA and get to the good stuff; otherwise you might as well just
browse our web site and read the whitepapers).
The way to get the real low-down is to come join us - a start-up
that is doing really exciting stuff, and become fabulously rich while
working on really interesting problems.
Q: What is Cloakware (the technology)
=====================================
Cloakware Technology makes software *effectively* tamper-proof. The
protected software still runs. For example, the protected software
could be a Java Class files - a boring standard compliant class file
that will run on any (correct) JVM. This protected software would be
very hard to tamper with. (Yes, there are some fine prints about what
"tamper" means).
Yes, we know about jamming branches, debuggers, emulators, reverse-
engineering tools. No, we are not nuts (at least I don't think so :-)
Q: How is Cloakware related to Nortel
=====================================
Cloakware Corporation is un-related to Nortel except that we hope to
sell to them (as we would hope for any other company). Some of the
people happens to have worked for Nortel in the past, and even filed
patent(s) in the same area. These patents are not related to the
activities at Cloakware.
Q: What is the patent status
============================
We, in Cloakware, have also filed a number of patents that cover new
ground. These patents are totally owned by Cloakware and not related
to Nortel. None of these patents have been granted yet nor have any
of them reached the publication date (that I know off), so you are
unlikely to find them on the net.
Q: How are we different from "shroud", "obfuscator", compiling, ...
===================================================================
The shrouds and obfuscators are very superficial. They merely remove
debugging information, rename variables, etc. Some commercial products
do a little bit more, but by and large, the program semantic is left
unchanged. There is no real challenge in fiddling them.
Compiling is slightly better. Many people would argue that a good
optimizing compiler is pretty good against reverse-engineering and
tampering; this is demonstratably not very strong - we have all done
patches on binary-only program. At most, one would call them "weakly
tamper-resistant" (or in Bruce's scale, good enough to prevent your
kid-sister from tampering.)
Cloakware Technology acts on a much deeper level and is much stronger.
Q: What is our threat model
===========================
We are aiming (which is to say we are not there yet, but think we can)
at a very severe threat-model: the attackers have all our patents,
publications and even internal documentation, they also have our
"encoder" (or what some people call the "cloaker") and can experiment
with it, they also have unlimited funds to get debuggers/emulators/...
as they wish. Even for this threat model, we hope to be able to make
it really expensive for the attacker.
Q: How are we different from "copy protection"
==============================================
The old Apple II and early PC saw lots of fun techniques dedicated to
preventing people from making copies. Typically, some trick was used
on the disk (half-track, quarter-track, spiral-track, burnt-spot were
amongst the most fun) and the code checked for the presence of these
tricks. The "crack" usually works by disabling these checks. This led
to an escalating war of protecting the S/W.
Many techniques were used to protect the S/W - checksums, encryption,
multiple layers of them, changing code already in the pre-fetch (to
defeat debuggers) and so on. They were all broken within days. They
were also often not portable (heck, many ran only on specific versions
of some chips).
In contrast, Cloakware is totally portable and (we believe) much
stronger.
Q: Can some tool automatically "de-cloak"?
==========================================
We don't think so (but I won't go into the details).
--
Stanley Chow VP Engineering [EMAIL PROTECTED]
Cloakware Corp (613) 271-9446 x 223
==============F883022655BD449E7CC0B431
Content-Type: text/x-vcard; charset=us-ascii;
name="stanley.chow.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Stanley Chow
Content-Disposition: attachment;
filename="stanley.chow.vcf"
begin:vcard
n:Chow;Stanley
tel;fax:(613) 271-9447
tel;work:(613) 271-9446 x 223
x-mozilla-html:FALSE
url:http:/www.cloakware.com
org:Cloakware Corp.
adr:;;260 Hearst way, suite 311;Kanata;Ontario;K2L 3H1;Canada
version:2.1
email;internet:[EMAIL PROTECTED]
title:VP Engineering
x-mozilla-cpt:;0
fn:Stanley Chow
end:vcard
==============F883022655BD449E7CC0B431==
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: OAP-L3: Semester 1 / Class #1 All are invited.
Reply-To: [EMAIL PROTECTED]
Date: Thu, 27 Apr 2000 20:37:33 GMT
In sci.crypt Joseph Ashwood <[EMAIL PROTECTED]> wrote:
: ya know, with Szopa here I kind of miss D Scott, he
: at least had the intelligence to find new personal attacks.
Mr Scott is still around - he posted in this ng only a couple of days ago.
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Be good, do good.
------------------------------
Subject: Re: The Illusion of Security
From: Diet NSA <[EMAIL PROTECTED]>
Date: Thu, 27 Apr 2000 13:54:47 -0700
In article <[EMAIL PROTECTED]>, Sean Glazier
<[EMAIL PROTECTED]> wrote:
>However there is a system that is built for the military that
uses the
>properties of inference
[I suspect you instead meant to type the word "interference".]
and what is dubbed as quantum encoding.
It works
>over short distances right now, but it is uncrackable since the
encoding
>cannot be observed with out destroying the communication link.
Is this system mentioned in the same IEEE issue? It has been
suggested that the NSA might be preparing (underground) quantum
encrypted fiber optic networks for the Pentagon. The
vulnerability of quantum crypto depends on the type of system
used and how it is implemented. Given that the NSA are not fools,
it is very unlikely (and perhaps even impossible) that an
eavesdropper could gain sufficient info from the NSA's?
implementation using *existing* technology.
Quite nice
>when you think of it. Impractical for all but military Command
and control
>applications.
Why does this have to be true?
>Since I don't think that we will be buying quantum computers in
the near
>future from comp usa, the encryption schemes are, for now, at
least safe
>from every one except governments who have the money to spend on
these
>devices.
It's not so much a question of money but instead of knowing how
to build a large & robust enough quantum computer (which no one
is certain of how to do yet). Plenty of people (including some
criminals) have the money needed, but not necessarily the
know-how, incentive, or access (especially to government labs).
" V hfdt afogx nfvw ufo axb (o)(o) " - Gtnjv
====================================================
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
From: [EMAIL PROTECTED] (Stefan Schlott)
Subject: Re: Secret splitting for kids' treasure hunt
Reply-To: [EMAIL PROTECTED] (Stefan Schlott)
Date: 27 Apr 2000 23:05:43 +0100
On 26 Apr 2000 19:27:51 -0700, Andru Luvisi <[EMAIL PROTECTED]> wrote:
>> 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).
>Could I trouble you to explain more about how this worked?
I'll try to explain the scheme for two shares - afair it is possible for
n shares, but I don't have my crypto books right here now (if you are
interested - tell me, then I'll try to find it).
The secret is a black and white picture. Double its size in each direction.
You will get 2x2 block being either completely black or white:
+--+ +--+
|XX| | |
|XX| or | |
+--+ +--+
The first share is randomly filled with the following blocks:
+--+ +--+
|X | | X|
| X| or |X |
+--+ +--+
The second share is built by comparing each pixel of the first share with
its correspondinge position in the secret picture: If the secret pixel is
white, use the same pattern as in the first share; otherwise, use the other
one.
Since the patterns in the first share were chosen randomly, you'll get
perfect secrecy (just like a one time pad).
The shares are combined by printing them on transparencies. Put them on
top of each other. Black pixels will become black (all four positions in
the pattern will be black); white pixels will be "50% gray" (two of the
four positions are black).
As I already mentioned, the proper positioning isn't as easy as one might
think right now... so don't make the "pixels" too small. Another hint:
Print the shares on transparencies rather than using a photocopying machine
(photocopiers might distort the picture making a proper matching almost
impossible).
Stefan.
--
*-- E-Mail: [EMAIL PROTECTED] ----------------- PGP key available on request --*
If Bill Gates had a dime for every time a Windows box crashed... oh, wait
a minute -- he already does.
-- Seen on Slashdot (19.04.2000)
------------------------------
From: Arthur Dardia <[EMAIL PROTECTED]>
Subject: Re: What came of it?
Date: Thu, 27 Apr 2000 17:06:27 -0400
"Gisle Sælensminde" wrote:
> In article <[EMAIL PROTECTED]>, _Andy_ wrote:
> >
> >A few months ago, there was a report in the newspapers (followed by a
> >discussion in this group) about a Welsh (I think) teenage girl who may
> >or may not have invented a cypher algorithm... I think matrices were
> >mentioned.
> >
> >I've looked back through the group history and can't find the relevant
> >threads.
> >
> >Does anyone know if anything came of it?
> >
> >
>
> You probably think of Sarah Flannery, who wrote a paper describing a new
> public key algorithm. In the original paper she described it as secure,
> but later she analysed and broke the algorithm herself. The paper can be
> found at:
>
> http://cryptome.org/flannery-cp.htm
>
> A short review in the cryptogram newsletter of december 99
>
> http://www.counterpane.com/crypto-gram-9912.html
> #SarahFlannerysPublic-KeyAlgorithm
>
> --
> Gisle Sælensminde ( [EMAIL PROTECTED] )
>
> ln -s /dev/null ~/.netscape/cookies
I still think she knew it was weak when she applied to MIT; however,
breaking your own credentials before being accepted into a top institution
would not be considered "smart."
But I guess I'm still bitter after being wait-listed. Heh. Rensselaer
Poly, here I come! (Unless of course CMU accepts me from the waiting list on
the CS/CE programs).
--
Arthur Dardia Wayne Hills High School [EMAIL PROTECTED]
PGP 6.5.1 Public Key http://www.webspan.net/~ahdiii/ahdiii.asc
------------------------------
Subject: Re: The Illusion of Security
From: Diet NSA <[EMAIL PROTECTED]>
Date: Thu, 27 Apr 2000 14:14:33 -0700
In article <8dtrsn$4pg$[EMAIL PROTECTED]>, David A Molnar
<[EMAIL PROTECTED]> wrote:
>A 7-qubit computer was recently announced. I think an
experimental
>verification of Shor's algorithm may not be far behind.
This 7-qubit approach can provide the necessary first step for
implementing traditional quantum algorithms (such as Shor's) in
liquid state NMR systems (see the journal "Nature" vol 404, page
368). I wouldn't be surprised to see a minor implementation of
Shor's algorithm within a year or two. No one knows if and when
it will be implemented at a level significant for crypto. Based
on the rate of qubit implementations achieved so far, we can
unjustifiably extrapolate a Moore's Law for quantum computing
that predicts there will be 30-qubit quantum computers in 5
years. Even these 30-qubit machines are likely to not be any
better than the non-quantum supercomputers in 2005.
" V hfdt afogx nfvw ufo axb (o)(o) " - Gtnjv
====================================================
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: new Echelon article
Date: Thu, 27 Apr 2000 20:24:41 GMT
"Douglas A. Gwyn" wrote:
> launcher business, although after the Columbia disaster
I of course meant the Challenger disaster. Sorry about that!
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: papers on stream ciphers
Date: Thu, 27 Apr 2000 20:27:02 GMT
"David A. Wagner" wrote:
> (Consider an IPSEC-encrypted session transporting an email to a SMTP
> server S. Suppose the email will subsequently be forwarded by S to T
> along a second SMTP link, this time in the clear. Then an attacker can
> send to S forged packets corresponding to the body of the email; S will
> decrypt them, treat the resulting plaintext as the body of an email, and
> forward the result to T in the clear. This gives the attacker the chance
> to see the deciphered "plaintext" by snooping the unencrypted S->T link.
> We are in essence treating S as a decryption oracle.)
If you snoop the result of S's decrypting using the correct key,
it seems to me you don't *need* to mount a chosen-plaintext attack!
------------------------------
From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: papers on stream ciphers
Date: 27 Apr 2000 14:15:26 -0700
In article <[EMAIL PROTECTED]>, Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
> "David A. Wagner" wrote:
> > (Consider an IPSEC-encrypted session transporting an email to a SMTP
> > server S. Suppose the email will subsequently be forwarded by S to T
> > along a second SMTP link, this time in the clear. Then an attacker can
> > send to S forged packets corresponding to the body of the email; S will
> > decrypt them, treat the resulting plaintext as the body of an email, and
> > forward the result to T in the clear. This gives the attacker the chance
> > to see the deciphered "plaintext" by snooping the unencrypted S->T link.
> > We are in essence treating S as a decryption oracle.)
>
> If you snoop the result of S's decrypting using the correct key,
> it seems to me you don't *need* to mount a chosen-plaintext attack!
But, in IPSEC, the key will typically also used for encrypting _other_
traffic which isn't also sent in the clear.
In general, whenever you've got network-level encryption, the same key
may be used for encrypting traffic from several different application
sessions, so if any one application allows this type of "forwarding",
all may be adversely affected.
------------------------------
** 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
******************************
