Cryptography-Digest Digest #300, Volume #13 Sat, 9 Dec 00 20:13:01 EST
Contents:
Re: How to embed a key in executable code? (David Schwartz)
Re: Hamming Distance ([EMAIL PROTECTED])
Re: [globera announcement 2] Professional support for Crypto++ available (Tom St
Denis)
Re: How to embed a key in executable code? ("Matt Timmermans")
Re: Why PDF and PS won't do it for a Personal Security Device
([EMAIL PROTECTED])
Re: [Question] Generation of random keys (Bryan Olson)
Re: document signing, XML canonicalization and why EDDF is a better choice
([EMAIL PROTECTED])
Re: How to embed a key in executable code? (Sundial Services)
Re: How to embed a key in executable code? (Sundial Services)
Re: Custom Encryption Algorithm (Chris Gillespie)
Re: DES_BCE64 ("TacTic")
Re: Disappeared into Oblivion? (Derek Bell)
Re: Custom Encryption Algorithm (Simon Johnson)
----------------------------------------------------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: How to embed a key in executable code?
Date: Sat, 09 Dec 2000 13:08:43 -0800
Eric Lee Green wrote:
> Not really. If you have a legal license, you just single step through the
> program until you find where it reads the license data off the disk. Then
> the programmer may have employed some obfuscation at this point -- e.g.,
> perhaps performs some algorithmic manipulations upon the data -- but
> usually you can single step past that to where he has set all his data
> variables such as, e.g., "number of users", and simply hard-wire that.
Unless it doesn't store that information in a variable and rechecks the
license data each time it needs it. Unless the program rereads the
license file later through separate code. Unless the license isn't on
the disk and is instead embedded in the executable. Unless a subsequent
crosscheck by the software would cause it to fail. Unless in order for
the "number of users" to be X, some other variable has to be Y.
There are a billion ways to make this hard. And every unit of effort
expended to make it hard requires at least ten units of effort to break.
DS
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Hamming Distance
Date: Sat, 09 Dec 2000 21:15:31 GMT
Jeremy Buhler <[EMAIL PROTECTED]> wrote:
> In general, this family of techniques goes by the name "exclusion methods."
> Check out the last decade or so of proceedings from CPM, the Combinatorial
> Pattern Matching conference, to find other examples.
Thank you muchly, those were exactly the sorts of references I was
looking for.
--
Matt Gauthier <[EMAIL PROTECTED]>
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: [globera announcement 2] Professional support for Crypto++ available
Date: Sat, 09 Dec 2000 21:17:51 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> IMHO the announcement was perfectly reasonable, on-topic, and not
spam.
> Although I have no evidence, positive or negative, about the
competence
> of this particular company, in general professional support for open-
source
> crypto libraries is something to be encouraged, and is likely to be of
> interest to a fair proportion of the readers of this group. At least
> they've chosen a well-designed library to support.
>
> Even if the article had been spam, quoting it in full and adding a
single
> line saying that it is spam in your opinion, is simply annoying, and
not
> at all helpful.
Not to drag this on forever (I respect that you have different views)
but unwarranted solicitation of services is SPAM. I do not remember
anyone specifically asking for "customer service". If they want to do
us a favour they should offer free services for the hobbiest.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Matt Timmermans" <[EMAIL PROTECTED]>
Subject: Re: How to embed a key in executable code?
Date: Sat, 09 Dec 2000 21:35:28 GMT
"Sundial Services" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> [...]
> A software protection scheme needs to be simple, sturdy, maintainable,
> and to be something that will not de-stabilize your program. (You have
> plenty enough "real" bugs to deal with.)
> [...]
Exactly -- there are other common design goals and constraints that prevent
you from implementing effective copy protection. Problems like this have
engineering solutions, though. What if you could do it without significant
modifications to your source code? What if you had software that could
transform your executables automatically into a program of provably
equivalent functionality that couldn't be compromised by reverse
engineering?
For instance:
Let's say I sell software over the Web. When you purchase my software, you
give me your name, address, and credit card number. Before uploading it to
you, I will embed your information in the executable. I could use common
optimization techniques to find alternate representations for many thousands
of little bits of code. I could encrypt your information with my private
key, and use secret sharing to expand the result to many thousands of bits
(but I only need a few of them to recover your information). I then use
these bits to select alternate representations for all those little code
bits. I will also write plaintext into the software that gives your name
and address and tells you what I've done.
Now, if you copy and distribute my software, I can always tell where the
illegal copies came from. Because I tell you this, it should be sufficient
to dissuade you. If it isn't, and you distribute my software widely,
chances are that I will be able to find a copy, extract your information,
and take you to court.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Why PDF and PS won't do it for a Personal Security Device
Date: Sat, 09 Dec 2000 21:43:35 GMT
denis bider <[EMAIL PROTECTED]> wrote:
> What I want to show is that EDDF has technical merits that make it
> better suited for most purposes than XML, and that similar technical
> merits make it more suitable for *some* purposes than, say, PDF or
> plain text. This point, I think, I have already shown.
If this is what you want to show, you should wander off to
comp.text.<wherever> and demonstrate that "EDDF has technical merits
that make it better suited for most purposes than XML" In particular,
that means:
1. The ability to check that any document is a valid instance of its
type definition.
2. The ability to painlessly include arbitrary amounts of non-EDDF data.
3. The ability to painlessly develop new document types.
4. The ability to represent arbitrary characters entities in a form
which can be parsed on any platform, even ones without support for the
given character set.
5. Enable easy searching based on document structure, regardless of
platform differences between the database and client plaforms.
And so on.
--
Matt Gauthier <[EMAIL PROTECTED]>
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: [Question] Generation of random keys
Date: Sat, 09 Dec 2000 21:55:03 GMT
David Schwartz wrote:
>
> Bryan Olson wrote:
> >
> > David Schwartz wrote:
> >
> > > By many definitions, a correlated stream is simply not random,
> > > whereas a biased stream can be random.
> >
> > Perhaps it would help if you stated a mathematically respectable
> > definition and listed a good reference.
>
> There was another thread all about this.
In the history of sci.crypt, there have been many, many
threads "about this".
> Several
> different definitions of random were presented, and the
> majority of them would not extend the concept 'random' to
> include correlated streams.
That's a summary of your conclusions about how people had
defined random. What I asked for is one mathematically
respectable definition and some reasonable reference.
> > In cryptology, by far the most accepted meaning of "random"
> > is in the sense of entropy as definied by Shannon.
> This would mean that there's no such thing as a PRNG.
I have no idea why you think that would follow. Do you
know that the 'P' stands for "pseudo" and what "pseudo"
means?
--Bryan
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: document signing, XML canonicalization and why EDDF is a better choice
Date: Sat, 09 Dec 2000 22:06:02 GMT
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>> I never have used an XML document nor do I know what one is.
> I thought you do have a web page. XML is the successor
> to HTML (a revised version so to say).
Actually, XML is more akin to a simplified SGML, not the successor to
HTML (although any successors will be defined in XML). It's equally
possible to develop other applications besides HTML in XML.
XML/SGML are standards for modeling different types of content based
on the structure of the contents. That is, there's a Document Type
Definition (DTD) for whatever document types you want to express such
as HTML, DocBook, SMDL (Standard Music Description Language),
etc. Individual documents are then instances of that type.
Typically, for every instance, the computer normally uses the embedded
structural tags in conjunction with a style sheet to transform the
instance into a different format for presentation. For example, a
chapter heading is rendered centered centered in boldface, music notes
may be convereted to bitmaps of their staff notation for display on a
gui, etc.
Much like the 3-tier database model, however, the layers are often
blended together. For example, a web browser normally includes a very
limited "parser" which can only parse HTML. On top of that, the
various style rules are typically hard coded in web browsers.
It's probably fair to say that the web is the poster child for how not
to mark up text. (Since it was only designed to handle physics papers,
however, that's understandable) Now that people are wanting to mark up
everything under the sun from books to poems, there's a press for the
more general functionality that the underlying standard
provides. Unfortunatly, there are a couple required features that made
making conformant parsers difficult to write. So, voila, remove the
troublesome features, call it XML and you've got a new standard with a
cooler acronym!
My apologies to everyone for this is old hat, as it is somewhat
off-topic. However, if you're going to have a meaningful discussion on
the suitability of a given format for digital signatures, everyone
involved should have at least a rough idea of what that format is.
--
Matt Gauthier <[EMAIL PROTECTED]>
------------------------------
Date: Sat, 09 Dec 2000 15:14:08 -0700
From: Sundial Services <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: How to embed a key in executable code?
>Eric Lee Green wrote:
> * License keys must not use any of the following characters in their
> encoding: 1 , l, O, 0, 2, Z. I can't tell you how many license key
> cards that I've looked at that were printed on some fuzzy dot matrix
> printer where I can't tell what I'm supposed to enter!
We compensated for this problem by intercepting keystrokes in the input
box and converting instances of 'I' or lowercase-'L' to "1", upshifting
lowercase characters and so forth. In other words, those ambiguous
characters are automatically translated into the correct ones.
>
> * The product must be usable as a demo product without a license key
> having been entered. That lets us put it on our FTP site as a demo
> product.
(This really isn't a sci.crypt point but ...) We recently eliminated<!>
the "demo product" mode from our product -- which, to be sure, has been
on the market since 1996 -- and found the move to be quite successful.
In its place we introduced a "30-day license" available for a song.
This is a fully-functional version, but time-limited. The time-limit is
embedded in the license code; the system date is checked through several
means.
In this way we are able to offer an unlimited set of functionality, no
nag-screens and so forth, for an economical price whether the user
wishes to "try it out" or, just as likely, feels that he/she only needs
it now-and-then.
It worked out extremely well.
==================================================================
Sundial Services :: Scottsdale, AZ (USA) :: (480) 946-8259
mailto:[EMAIL PROTECTED] (PGP public key available.)
> Fast(!), automatic table-repair with two clicks of the mouse!
> ChimneySweep(R): "Click click, it's fixed!" {tm}
> http://www.sundialservices.com/products/chimneysweep
------------------------------
Date: Sat, 09 Dec 2000 15:25:18 -0700
From: Sundial Services <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: How to embed a key in executable code?
Okay, Matt, I hear what you are saying "as a technologist," but now let
me show you the other side of the coin. I mean this, not to refute what
you are saying, but to show the "hidden cost" of this approach.
Each time someone buys software from you, you have to get involved. You
have to embed information and upload the file -- then I have to
laboriously download it over my puny 28.8K modem connection -- and
already I'm wondering to myself if this product is really good enough to
justify all this. Furthermore, all your warnings of the dire things
that you could (indeed...) do to me if I steal your software -- are
smacking of the fact that you are openly "calling me a thief and a
liar." As a fellow-human-being that rubs me the wrong way. It raises
the fur on my back; it gives me a bottle-brush tail. It makes me spit
and hiss instead of purr.
And, it's raising the cost and duration of each sale enormously. What
-if- you sold 20 or 50 or 100 copies per day of your
suddenly-wildly-successful product? What -if- you discovered a bug (oh
my!) and had to re-issue individually-encrypted products to 3,500
customers at one time? {That's about the number of licensees we have
today.}
Suddenly your cost-of-sales is going sky-high, and you're annoying your
customers which is -never- a good thing to do.
This is one of the reasons why retail stores have this thing called
"shrink." It's a fancy name for the losses that they incur, and plan
for, as a result of "the customer is stealing you blind." They know
that a certain amount of product is -going- to walk out the door. They
have a pretty good idea of what percentage of their inventory is going
to do that. (Obviously software plays by different rules.) There might
be more aggressive loss-prevention steps that they -could- take, like
posting an armed guard at the door to check your receipt as some
electronics stores in-fact *do*, but there's a cost for that.
>Matt Timmermans wrote:
> Let's say I sell software over the Web. When you purchase my software, you
> give me your name, address, and credit card number. Before uploading it to
> you, I will embed your information in the executable. I could use common
> optimization techniques to find alternate representations for many thousands
> of little bits of code. I could encrypt your information with my private
> key, and use secret sharing to expand the result to many thousands of bits
> (but I only need a few of them to recover your information). I then use
> these bits to select alternate representations for all those little code
> bits. I will also write plaintext into the software that gives your name
> and address and tells you what I've done.
>
> Now, if you copy and distribute my software, I can always tell where the
> illegal copies came from. Because I tell you this, it should be sufficient
> to dissuade you. If it isn't, and you distribute my software widely,
> chances are that I will be able to find a copy, extract your information,
> and take you to court.
--
==================================================================
Sundial Services :: Scottsdale, AZ (USA) :: (480) 946-8259
mailto:[EMAIL PROTECTED] (PGP public key available.)
> Fast(!), automatic table-repair with two clicks of the mouse!
> ChimneySweep(R): "Click click, it's fixed!" {tm}
> http://www.sundialservices.com/products/chimneysweep
------------------------------
Date: Sat, 09 Dec 2000 23:50:49 +0000
From: Chris Gillespie <[EMAIL PROTECTED]>
Subject: Re: Custom Encryption Algorithm
I think it is important to point out to the original poster the reason
WHY an algorithm with a fixed/no key isn't secure. The main reasoning to my
mind is that the software to implement it can be reversed and the algorithm
becomes insecure thereafter, and saying that the software or algorithm
details will never fall into the wrong hands isn't a valid excuse. Just to
say "it is insecure" doesn't help, if I take an algorithm like 3DES and
have a fixed key in my implementation the the ciphertext is still as secure
as if I took a random key, as long as the endpoints (i.e encryptor and
decryptor) remain secure.
I know it is annoying for those experienced readers of this group to read
messages like the one posted, but you must remember that newbies read it
to, and the best way to learn is to try.
Chris.
------------------------------
From: "TacTic" <[EMAIL PROTECTED]>
Crossposted-To: alt.sources.crypto,list.cryptography
Subject: Re: DES_BCE64
Date: Sun, 10 Dec 2000 00:30:38 -0000
I have been asked for information on DES_BCE64 by a friend in the Gov so I
only asume that is the righ way round??? Any info would be of help.
"Tom St Denis" <[EMAIL PROTECTED]> wrote in message
news:90rt3n$ebg$[EMAIL PROTECTED]...
> In article <90rd21$61i$[EMAIL PROTECTED]>,
> "TacTic" <[EMAIL PROTECTED]> wrote:
> > I need source of information on DES_BCE64 please!
> >
>
> Where did you hear of BCE? Do you mean ECB? That's the native usage
> mode of any block cipher.
>
> Tom
>
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
------------------------------
From: Derek Bell <[EMAIL PROTECTED]>
Subject: Re: Disappeared into Oblivion?
Date: 10 Dec 2000 00:35:27 -0000
Simon Johnson <[EMAIL PROTECTED]> wrote:
: I remember reading in a paper, around a year ago, about a 16yrd girl
: (who i think was scottish) who was meant to have designed an innovative
: public key algorithm?
Her name is Sarah Flannery,she's from Co. Cork, Ireland, and she's
disovered an attack on it.
The website is http://www.cayley-purser.ie/
Derek
--
Derek Bell [EMAIL PROTECTED] | Socrates would have loved
WWW: http://www.maths.tcd.ie/~dbell/index.html| usenet.
PGP: http://www.maths.tcd.ie/~dbell/key.asc | - [EMAIL PROTECTED]
------------------------------
From: Simon Johnson <[EMAIL PROTECTED]>
Subject: Re: Custom Encryption Algorithm
Date: Sun, 10 Dec 2000 00:47:54 GMT
In article <[EMAIL PROTECTED]>,
Chris Gillespie <[EMAIL PROTECTED]> wrote:
> I think it is important to point out to the original poster the reason
> WHY an algorithm with a fixed/no key isn't secure. The main reasoning
to my
> mind is that the software to implement it can be reversed and the
algorithm
> becomes insecure thereafter, and saying that the software or algorithm
> details will never fall into the wrong hands isn't a valid excuse.
Just to
> say "it is insecure" doesn't help, if I take an algorithm like 3DES
and
> have a fixed key in my implementation the the ciphertext is still as
secure
> as if I took a random key, as long as the endpoints (i.e encryptor and
> decryptor) remain secure.
If you write the KEY directly into an application, then there is no
security because i can just rip the key out the program. If you mean
something else, it is poorly phrased.
> I know it is annoying for those experienced readers of this group to
read
> messages like the one posted, but you must remember that newbies read
it
> to, and the best way to learn is to try.
>
> Chris.
>
>
Nah, you really misunderstand here. We _cannot_ give him anymore
information about why his cipher is insecure because we has produced no
algorithm, just a lump of cipher-text. I can reason based on the
frequencies of particular letter that the cipher is probably insecure,
but any more than this is just sprinkling fairy dust.
Tom's suggestion is probably correct: Its probably either a
Monoalphabetic or polyalphabetic. But why should i spend time
determining this is the case, when the original poster didn't spend the
time to post the algorithm?
Simon.
--
Hi, i'm the signuture virus,
help me spread by copying me into Signiture File
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
** 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
******************************
