Cryptography-Digest Digest #296, Volume #13 Sat, 9 Dec 00 03:13:00 EST
Contents:
Re: How to embed a key in executable code? ("Matt Timmermans")
Re: document signing, XML canonicalization and why EDDF is a better (Roger Schlafly)
Re: [Question] Generation of random keys (Benjamin Goldberg)
Re: weten we die PIN? ([EMAIL PROTECTED])
Re: How to embed a key in executable code? (Eric Lee Green)
Re: How to embed a key in executable code? (Eric Lee Green)
Re: How to embed a key in executable code? (Sundial Services)
Re: What's better CAST in PGP or Blowfish 128bit? ("Noname")
Re: [Question] Generation of random keys (David Schwartz)
Re: How to embed a key in executable code? (David Schwartz)
----------------------------------------------------------------------------
From: "Matt Timmermans" <[EMAIL PROTECTED]>
Subject: Re: How to embed a key in executable code?
Date: Sat, 09 Dec 2000 04:22:09 GMT
"Mike Rosing" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> That's because it's an intrinsic property of hardware. It doesn't matter
how
> convoluted your thought process is, if it's embedded into a physical
device
> then the physical properties can be measured.
Reverse engineering takes more than measurement -- it takes understanding.
There is a difference between things like DVD copying, which doesn't require
reverse engineering, because you can always just capture the output, and
removing license information that's been well hidden in an .exe.
------------------------------
From: Roger Schlafly <[EMAIL PROTECTED]>
Subject: Re: document signing, XML canonicalization and why EDDF is a better
Date: Fri, 08 Dec 2000 20:50:06 -0800
denis bider wrote:
> ?The main advantage of EDDF seems to be that it uses ASN.1 DER
> ?instead of XML. This seems like a step backwards to me. Who
> ?wants to sign an ASN.1 document?
>
> thank you for this comment. This might be a common misconception, and
> it is something that I would like to clarify.
>
> First of all, the strength of EDDF is not inherent in its use of DER.
> Indeed, it is certainly possible to design a data format that would
> use DER and retain all the weaknesses of XML. What makes EDDF stronger
> is not the use of DER on its own, but rather that the format is
> designed entirely with document canonicality in mind. Every step in
> the creation of an EDDF document must be compatible with the basic
> premise that the document's ultimate form should be the only possible
> form. This could have been done on a textual basis just as well - the
> fact that it would be text-based would just make the rules more
> difficult to verbalize and implement.
>
> DER was, therefore, a matter of my personal choice.
>
> I do not know whether the general public regards ASN.1 as a thing of
> the past - especially when compared to a newer technology like XML.
> Nevertheless, I think that such an opinion would be a fairly
> superficial one, and would be a likely candidate for reversal after
> the XML hype is over.
>
> The reasons behind a judgement that DER is "backwards" would probably
> have something to do with the fact that XML can be read in a text
> editor; and DER cannot. And that XML can be created with a text
> editor; while DER cannot.
Also, XML has a simple syntax that is easy to understand and parse.
ASN.1 DER is not all that hard, but it is a lot more complicated
than it needs to be for the purposes for which it is commonly used.
Programmers dislike it. As a results, systems that use ASN.1
commonly have ASN.1-related bugs.
> The fact is, XML is just as impractical for human inspection as DER. I
> have had the privilege of working with XML in a real life environment.
> In such an environment, the majority of XML documents that you meet
> are computer-generated. These XMLs are usually all stuffed in a single
> line, no formatting involved, and this is rightly so; such documents
> are more compact, easier to generate and easier to process. However,
> they are also very difficult to navigate by hand. What you need to
> work with these XML documents is... A VIEWER.
Ok, so XML is not perfect. Do you really think the world is going
to switch to your document format just because it is no worse
than XML and maybe even slightly better for some narrow particular
purpose?
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: [Question] Generation of random keys
Date: Sat, 09 Dec 2000 05:19:47 GMT
David Schwartz wrote:
>
> Benjamin Goldberg wrote:
>
> > David Schwartz wrote:
>
> > > Benjamin Goldberg wrote:
>
> > > > Umm, Alan is saying that it's impossible to algorithmically
> > > > perform a real-world physical act. Code can simulate a coin
> > > > flip, but not actually do one. Anyone who believes that they
> > > > can algorithmically generate random number is in a state of sin.
> > > > (Name that quote!)
>
> > > By what definition of "random" is it impossible to
> > > algorithmically convert non-random numbers into random ones?
>
> > My definition of a random source is one that has finite or zero
> > state, and produces a stream of values that never degenerates into
> > a continually repeating cycle.
>
> I'm not at all clear on what you mean by "finite or zero
> state". It sounds to me like this would include lots of things we
> don't normally consider random.
Stateless [eg, a coin], or with bounded state, like a hidden markov
model.
> > However, I do not claim that all random sources are equally good.
> > Id est, do I claim that every bit of output must have 1 bit of
> > entropy for the source to be random.
> >
> > Any algorithm which starts with a state, and recieves no exterior
> > inputs is a non-random number source. An algorithm which *filters*
> > data, however, *can* output random numbers, provided that a random
> > stream is input it to it, and it doesn't remove the randomness from
> > that stream.
>
> Neither of these things are the issue. The issue is whether an
> algorithm can convert an unlimited quantity of input data that is not
> random into an unlimited quantity of output data that is random. And I
> submit that an algorithm _can_ unless by "random" you mean exactly the
> same thing as "unpredictable".
I suppose I do. I don't see anything wrong with using random and
unpredictable to mean the same thing. A bitstream can be anywhere from
100% predictable, (every bit can be predicted) to 0% predictable (you
can predict bits with no more than 50% accuracy). You seem to want to
define "random" as 100% predictable, wheras I consider that if a stream
has nonzero unpredictability, it's "random".
> > > You would have to accept biased numbers as random, no
> > > matter how heavy the bias, because you can algorithmically remove
> > > bias.
> >
> > Yes and no. I can accept biased as random (low quality random, but
> > still random), but that does not mean that an algorithmic removal of
> > bias necessarily removes the property of randomness. However, using
> > *just* an algorithm (and a finite sized seed) cannot produce random
> > numbers.
>
> You are missing my point. My point is that an algorithm that
> removed bias would increase randomness.
"Increase" the randomness?!?! Now your admiting that there is
randomness there in the first place! I do indeed admit that an
algorithm that removed bias can increase randomness, if randomness is
input to it. However, a bias remover, by itself, cannot create
randomness, if a non-random stream (0% unpredictable) is not fed into
it.
> > > You would have to accept correlated numbers as random,
> > > because you can algorithmically remove correlation.
>
> > Again, although I can accept correlated numbers as random, this does
> > not mean that they are high quality random. Also, using an
> > algorithm to remove correlation does not remove randomness. It is
> > only using an algorithm to *produce* numbers that produces
> > non-random values.
>
> Again, I'm arguing the reverse. Using an algorithm to remove
> correlation increases randomness. And the amazing thing is that you
> can remove correlation _without_ decreasing the data rate.
A decorrelator can indeed increase randomness. However, it cannot, by
itself, create randomness. It needs a random input stream to output
randomness. The randomness is not produced by the algorithm, merely
condensed with it.
> > > In fact, you would have to accept practically anything
> > > that was to any extent unpredictable as "random". Because
> > > unpredictability is the _only_ thing you can't create
> > > algorithmically.
>
> > Why yes, you are exactly correct.
>
> > We can, algorithmically, convert a low quality random stream into a
> > higher quality random stream, with a reduced number of bits/second,
> > but we can't algorithmically produce random numbers without having a
> > random input stream.
>
> Actually, we can lagorithmically covert a low quality random
> stream into a higher quality random stream with NO change in the bit
> rate.
> Consider the following stream:
>
> 0000000000000111111111111111110000000000000000011111
> 11111111111111111100000000000000000011111111111111111
>
> It's highly correlated. We can remove that correlation, and
> thus improve the randomness like this:
>
> 0000000000000100000000000000001000000000000000010000
> 00000000000000000010000000000000000010000000000000000
>
> Note that no reduction in bit rate occurs.
You have changed a correlated stream into a biased stream. This is not
an increase in quality. Also, you referred to the unpreditctability as
'randomness'. It seems you are getting your terms confused. I repeat
again, I consider that a stream with nonzero unpredictability is random,
or contains randomness.
> There are two things you can say about algorithms, however:
>
> 1) They can't create unpredictability.
Right. They can't create randomness. Only transform it.
>
> 2) They can't have more possible output values than they have
> possible input value.
Right. If an algorithm is fed a stream with nonzero unpredictability,
it can produce an output stream which will have greater
unpredictability, but with lower bit rate. If the number if bits/bit of
entropy is known, we can even algorithmically change transform the
stream to one that is nearly 100% unpredictable.
--
There are three methods for writing code in which no bug can be found:
1) Make the code so straightforward that there are obviously no bugs.
2) Make the code so complicated that there are no obvious bugs.
3) Insist that any apparent bugs were really intentional features.
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To:
alt.cracks.nl,alt.nl.telebankieren,nl.comp.crypt,nl.financieel.bankieren,nl.juridisch
Subject: Re: weten we die PIN?
Date: Sat, 09 Dec 2000 05:38:00 GMT
On Fri, 08 Dec 2000 08:28:36 GMT, [EMAIL PROTECTED] (David Dylan) wrote:
>On 7 Dec 2000 22:09:58 GMT, John <[EMAIL PROTECTED]> wrote:
>
>Hoi hoi,
>
>>Geen van beiden, het wordt namelijk op de kaart zelf bijgehouden.
>
>Dat is wel het meest logische vanuit een efficiency standpunt, maar is
>het ook veilig? Inbreken in een banksysteem lijkt mij een end lastiger
>dan op je gemak in een achterkamertje met een paar nerds de code op
>een kaart uitdokteren... Of zie ik dat nu helemaal verkeerd?
>
>Je verzamelt een paar kaarten waar je de PIN van weet, en kijk &
>vergelijk... (simpel gezegd)...
>
>Groetz.
Elke ontwikkelde code is kraakbaar, uitsluitend de factor " tijd " is
de grootste belemmering. Ergo de pincode is nooit voor 100% veilig,
doch om deze te kraken dien je wel de beschikking over de kaart te
hebben, anders heb je 10.000 min 1 mogelijkheden.
Ton
------------------------------
From: [EMAIL PROTECTED] (Eric Lee Green)
Subject: Re: How to embed a key in executable code?
Reply-To: [EMAIL PROTECTED]
Date: Sat, 09 Dec 2000 06:06:24 GMT
On Fri, 08 Dec 2000 19:24:21 -0800, David Schwartz <[EMAIL PROTECTED]> wrote:
> Actually, the software that's at precisely the highest risk is software
>that is:
>
> 1) Easily available, for example, publically downloadable.
>
> 2) Of general interest, and of special interest to people with the
>highest ability to defeat its protection, and
>
> 3) reliant on licensing files or keys to control features, as opposed
>to not releasing the software for those features.
>
> That's why ConferenceRoom is such an interesting case. It meets all
>three requirements in spades, and is a very popular request among
>pirates. It's available for free from our web page, but relies on
>'license keys' to control access to advanced features. I believe it's
>software protection scheme is one of the best in existence.
>Nevertheless, it has seen three minor breaks in as many years (since the
>new scheme was put in place). However, nobody has managed to bypass the
>license check without severely compromising normal operation.
That would be a challenge, but not a large one. At least, not to the
typical cracker of the early 80's. I wonder if the world of crackerdom
has gone downhill since the early 80's, when those of us who had
skills had real incentive to crack programs (so that we could put
programs we owned onto our hard drives -- programs in those days were
distributed on copy-protected floppies, it was infuriating to wait for
a 360k floppy to load when you had a 20gb Winchester that was 20 times
faster, especially for programs that you'd paid hundreds of dollars
for and the @#$%@ thing is on a #$%@ unreliable disposable floppy that
could self-destruct at any time?). The crack *WOULD* require buying a
fully-enabled license, but that didn't stop us in the early 80's. But
then, we had skills and jobs, and maybe modern day script kiddies have
neither?
Or maybe it's just that I've written a licensing scheme similar to the
one you describe (it's in BRU, which is publically downloadable as a
demo product, then if you decide to buy it we can send you license
strings to enable it), and know how easily it could be bypassed by
someone with my skills. The fact that it has not been bypassed is not
a factor of it being difficult to bypass. It's more a case of BRU not
being of interest to cracker types -- they just use 'tar' or 'dump' if
they back up at all (most of those types, I find, don't believe in
backups, maybe because they're afraid of what the FBI would find in
backup tapes :-).
--
Eric Lee Green There is No Conspiracy
[EMAIL PROTECTED] http://www.badtux.org
------------------------------
From: [EMAIL PROTECTED] (Eric Lee Green)
Subject: Re: How to embed a key in executable code?
Reply-To: [EMAIL PROTECTED]
Date: Sat, 09 Dec 2000 06:11:38 GMT
On Sat, 09 Dec 2000 04:22:09 GMT, Matt Timmermans <[EMAIL PROTECTED]> wrote:
>"Mike Rosing" <[EMAIL PROTECTED]> wrote in message
>news:[EMAIL PROTECTED]...
>> That's because it's an intrinsic property of hardware. It doesn't matter
>how
>> convoluted your thought process is, if it's embedded into a physical
>device
>> then the physical properties can be measured.
>
>Reverse engineering takes more than measurement -- it takes understanding.
>There is a difference between things like DVD copying, which doesn't require
>reverse engineering, because you can always just capture the output, and
>removing license information that's been well hidden in an .exe.
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.
Any competent programmer with the prerequisite mentality could do it
using either built-in debugging facilities of the processor or, if
they did not suffice, a CPU emulator. Granted, it takes patience, and
some amount of skills. But if I could do it when I was a callow
ignorant young lad of 18 (I'm significantly older, smarter, and wiser
now, don't want to say HOW much older due to the amount of age
discrimination in this industry), I'm pretty sure it's not exactly
brain surgery.
--
Eric Lee Green There is No Conspiracy
[EMAIL PROTECTED] http://www.badtux.org
------------------------------
Date: Fri, 08 Dec 2000 23:21:58 -0700
From: Sundial Services <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: How to embed a key in executable code?
Give me any software protection scheme and I assure you that it will be
or has been broken, by one of the many "warez" artists who circulate
around the web. These people have enormous skill, anomnity, patience
and time. And the willingness to do it; for them, it's fun. (And
actually .. ahem .. well, anyway.)
I feel that the most important quality of a software mechanism is ...
that it exists. The door =is= locked. It does not have to be locked
with four inches of chromium steel.
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.) Above all, it should not
inconvenience the legitimate purchasers who paid good money for your
product. And it should not dissuade anyone from choosing to buy...
which it certainly =can= do.
"I have an allergic aversion to dongles of any kind." (For example.)
Dongles =mean= "no sale" to me. So does a license-code that requires me
to log-on or call someone to install on a particular machine. ("You
don't trust me, do you?") You're making your software hard for me to
own, and so I'm going to gravitate toward a different program that is
easier to manage.
>Matt Timmermans wrote:
>
> You missed the important part. To prevent copies, the signature must tie
> the software to a CPUID, ethernet address, or something like that. In the
> absence of all of these, you have to tie the software to a plaintext license
> file that has the user's name and address in it and clearly visible, or make
> it put that information up in a splash screen when it starts. Having their
> name and address in the file is enough to dissuade a would-be pirate from
> distributing illegal copies.
>
> This can only be practically defeated by reverse engineering, so the
> question is: "Is reverse engineering always possible"?
>
==================================================================
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
------------------------------
From: "Noname" <[EMAIL PROTECTED]>
Subject: Re: What's better CAST in PGP or Blowfish 128bit?
Date: Fri, 8 Dec 2000 19:37:49 +0100
Yes, I need to learn and therefore I'm here:o)). Is it a problem? I cannot
know everything:o)). I am coder and I need to include encryption into my
product.
And that's all. So for me is crypting only algorithm with input and output.
Tom St Denis <[EMAIL PROTECTED]> píše v diskusním
příspěvku:90kblp$b3o$[EMAIL PROTECTED]
> In article <90jlus$2rpc$[EMAIL PROTECTED]>,
> "Noname" <[EMAIL PROTECTED]> wrote:
> > I need strong algorithm and it can be slow in encrypt/decrypt. I need
> the
> > best:o).
>
> You need to learn about crypto is what you need.
>
> Tom
>
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: [Question] Generation of random keys
Date: Fri, 08 Dec 2000 23:30:55 -0800
Benjamin Goldberg wrote:
> You have changed a correlated stream into a biased stream. This is not
> an increase in quality. Also, you referred to the unpreditctability as
> 'randomness'. It seems you are getting your terms confused. I repeat
> again, I consider that a stream with nonzero unpredictability is random,
> or contains randomness.
By many definitions, a correlated stream is simply not random, whereas
a biased stream can be random. So converting a correlated stream into a
biased stream _is_ an incrase in randomness, by the most common
definitions.
However, I personally prefer to treat the words "random" and
"unpredictable" as synonymous. The extent to which something is random
(with respect to something) is the extent to which that something can't
predict it.
DS
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: How to embed a key in executable code?
Date: Fri, 08 Dec 2000 23:34:43 -0800
Eric Lee Green wrote:
> That would be a challenge, but not a large one. At least, not to the
> typical cracker of the early 80's. I wonder if the world of crackerdom
> has gone downhill since the early 80's, when those of us who had
> skills had real incentive to crack programs (so that we could put
> programs we owned onto our hard drives -- programs in those days were
> distributed on copy-protected floppies, it was infuriating to wait for
> a 360k floppy to load when you had a 20gb Winchester that was 20 times
> faster, especially for programs that you'd paid hundreds of dollars
> for and the @#$%@ thing is on a #$%@ unreliable disposable floppy that
> could self-destruct at any time?). The crack *WOULD* require buying a
> fully-enabled license, but that didn't stop us in the early 80's. But
> then, we had skills and jobs, and maybe modern day script kiddies have
> neither?
There's another issue involved here. If the copy protection or
licensing scheme interferes with normal lawful usage, then there is a
very large incentive to break it. Similarly, if the software is
overpriced with respect to the funcionality it provides, then again
there is a strong incentive to break it. If similar functionality is
available in free software, that reduces the incentive to break it.
Given sufficient incentive, any scheme can be broken. The best the
designer of such a scheme can do is make the effort involved as high as
possible and hope nobody bothers.
If somebody does break the scheme, you can change it radically for the
next release. So at least their efforts won't allow them to get new
features. For this reason, it's fairly important for those concerned
with software protection to follow what the pirates are doing.
DS
------------------------------
** 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
******************************
