Home > Archive > Unix Programming > July 2007 > hiding a counter
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
|
|
| Seth7TS@gmail.com 2007-07-05, 8:06 am |
| Hi,
i need to increment a counter every time a software is launched(i
would like to do a sort of trial version)...I have no idea how to hide
it and where...
can someone help me??
thanks
Seth
| |
|
| Seth7TS wrote:
> i need to increment a counter every time a software is launched(i
> would like to do a sort of trial version)...I have no idea how to hide
> it and where...
> can someone help me??
> thanks
Just use the registry. That's what it's for, after all, isn't it?
*cough*
| |
| David Schwartz 2007-07-05, 8:06 am |
| On Jul 5, 2:53 am, Seth...@gmail.com wrote:
> i need to increment a counter every time a software is launched(i
> would like to do a sort of trial version)...I have no idea how to hide
> it and where...
> can someone help me??
> thanks
I'll tell you what. If you help me with my problem, I'll help you with
yours. I have $174,000 in cash that I need a good hiding place for.
Someplace thieves would never look. If you tell me where to hide my
cash, I'll tell you where to hide your counter.
DS
| |
| Boltar 2007-07-05, 8:06 am |
| On 5 Jul, 10:53, Seth...@gmail.com wrote:
> Hi,
> i need to increment a counter every time a software is launched(i
> would like to do a sort of trial version)...I have no idea how to hide
> it and where...
> can someone help me??
> thanks
I would suggest getting the program to modify its own binary each
time it runs but as you can see from another post of mine I'm having
trouble getting that to work. Other than that you're limited to hiding
a file in an obscure place or using a shared memory segment though
obviously that could be deleted by any sys admins or clued up users
using the same login id as the process.
B2003
| |
| Pascal Bourguignon 2007-07-05, 8:06 am |
| Seth7TS@gmail.com writes:
> i need to increment a counter every time a software is launched(i
> would like to do a sort of trial version)...I have no idea how to hide
> it and where...
> can someone help me??
> thanks
On unix systems a good way to hide data is in memory.
Indeed, people often use ls, but rarely use ipcs.
You could open a shared memory segment, and store your counter here.
Of course, it would be reset everytime the computer is rebooted, but
this is rare.
% uptime
14:58:21 up 155 days, 18:57, 0 users, load average: 0.01, 0.01, 0.00
It is also possible to hide it in a "server" process.
Nowadays, while it would be a PITA for the users (and you couldn't
hope me to pay for a software that would do that), you could request
internet connectivity to use your software so you could store the
counter in YOUR servers.
--
__Pascal Bourguignon__ http://www.informatimago.com/
| |
| David Schwartz 2007-07-05, 7:08 pm |
| On Jul 5, 2:53 am, Seth...@gmail.com wrote:
> i need to increment a counter every time a software is launched(i
> would like to do a sort of trial version)...I have no idea how to hide
> it and where...
> can someone help me??
> thanks
This tends to not work very well. I would suggest you come up with an
alternate approach.
One possibility would be to reduce the functionality of the trial
version. Make sure there's enough functionality to convince someone
that your software is useful but not enough that the trial version
becomes a substitute for the real thing.
For the case where a person really does need to try out a full version
of the software, you can authorize them to do this over the Internet.
This means someone would have to have Internet connectivity to start
your software while they were trying out the full version, but this is
seldom a significant limitation.
DS
| |
| Måns Rullgård 2007-07-05, 7:08 pm |
| Pascal Bourguignon <pjb@informatimago.com> writes:
> Seth7TS@gmail.com writes:
>
> Nowadays, while it would be a PITA for the users (and you couldn't
> hope me to pay for a software that would do that), you could request
> internet connectivity to use your software so you could store the
> counter in YOUR servers.
What's to stop me patching over the bit of code that connects to the
server?
The OP's problem is unsolvable.
--
Måns Rullgård
mans@mansr.com
| |
| Rainer Weikusat 2007-07-05, 7:08 pm |
| Måns Rullgård <mans@mansr.com> writes:
> Pascal Bourguignon <pjb@informatimago.com> writes:
>
> What's to stop me patching over the bit of code that connects to the
> server?
>
> The OP's problem is unsolvable.
Technically, yes. But the real point behind these schemes is usually
that some non-technical person being deeply convinced that humans are
dishonest by design reaches a 'this would certainly be to complicated
for me' peace-of-mind state.
| |
| David Schwartz 2007-07-05, 10:06 pm |
| On Jul 5, 2:31 pm, M=E5ns Rullg=E5rd <m...@mansr.com> wrote:
> What's to stop me patching over the bit of code that connects to the
> server?
If you patch over the code that connects to the server, you won't get
the data the server would have sent you in reply. If this data is
critical to the operation of the program (it could even be a critical
piece of executable code even) then the program will not function.
> The OP's problem is unsolvable.
The problem of designing a public key encryption system is provably
unsolvable as well with the same types of assumptions you are making
in your argument that this problem is unsolvable.
Basically, you are simply disagreeing with the OP over what the
problem is.
Here's an argument as good as yours that the OP's problem is
unsolvable: Since the OP was able to write the program to do whatever
it is the program does, anyone could simply write their own program
that does the same thing. Therefore nothing you can do will force them
to buy your program if they want its functionality.
DS
| |
| Måns Rullgård 2007-07-06, 4:15 am |
| David Schwartz <davids@webmaster.com> writes:
> On Jul 5, 2:31 pm, Måns Rullgård <m...@mansr.com> wrote:
>
>
> If you patch over the code that connects to the server, you won't get
> the data the server would have sent you in reply. If this data is
> critical to the operation of the program (it could even be a critical
> piece of executable code even) then the program will not function.
So allow the connection once, dump the state of the program resume
from there next time you need to run it.
>
> The problem of designing a public key encryption system is provably
> unsolvable as well with the same types of assumptions you are making
> in your argument that this problem is unsolvable.
The problem is unsolvable for the same reason DRM is impossible.
--
Måns Rullgård
mans@mansr.com
| |
| Rainer Weikusat 2007-07-06, 4:15 am |
| David Schwartz <davids@webmaster.com> writes:
> On Jul 5, 2:31 pm, Måns Rullgård <m...@mansr.com> wrote:
>
> If you patch over the code that connects to the server, you won't get
> the data the server would have sent you in reply. If this data is
> critical to the operation of the program (it could even be a critical
> piece of executable code even) then the program will not function.
>
>
> The problem of designing a public key encryption system is provably
> unsolvable as well with the same types of assumptions you are making
> in your argument that this problem is unsolvable.
'Public key encryption systems' depend on certain secrets remaining
secret. But if somebodoy possesses a binary which is capable of
actually running, all the information necessary to make it run must be
avaible to him, meaning there is no secrecy but just a certain level
of obfuscation *and* the de-obfuscating code.
[...]
> Here's an argument as good as yours that the OP's problem is
> unsolvable: Since the OP was able to write the program to do whatever
> it is the program does, anyone could simply write their own program
> that does the same thing. Therefore nothing you can do will force them
> to buy your program if they want its functionality.
You have dropped an important premise. The starting point was that
somebody wants to use this program to accomplish something.
| |
| Barry 2007-07-06, 10:05 pm |
|
"Rainer Weikusat" <rweikusat@mssgmbh.com> wrote in message
news:87zm2ac55n.fsf@fever.mssgmbh.com...
> David Schwartz <davids@webmaster.com> writes:
>
> 'Public key encryption systems' depend on certain secrets remaining
> secret. But if somebodoy possesses a binary which is capable of
> actually running, all the information necessary to make it run must be
> avaible to him, meaning there is no secrecy but just a certain level
> of obfuscation *and* the de-obfuscating code.
This could be made infinitely obfuscating.
But, the likelihood that anyone who has to ask this question, writes
code someone would bother to steal is remote.
>
> [...]
>
>
> You have dropped an important premise. The starting point was that
> somebody wants to use this program to accomplish something.
| |
| David Schwartz 2007-07-06, 10:05 pm |
| On Jul 6, 1:07 am, M=E5ns Rullg=E5rd <m...@mansr.com> wrote:
> So allow the connection once, dump the state of the program resume
> from there next time you need to run it.
That won't work. If you resume from there, the connection will no
longer exist. All the program needs to do is make sure the connection
is still there.
For every move you make, there's a counter-move I can make. The
problem is, I have to make all my moves before you even get to the
table. So it comes down to whether or not I can anticipate every move
you might make.
DS
| |
| David Schwartz 2007-07-06, 10:05 pm |
| On Jul 6, 1:23 am, Rainer Weikusat <rweiku...@mssgmbh.com> wrote:
[color=darkred]
> 'Public key encryption systems' depend on certain secrets remaining
> secret. But if somebodoy possesses a binary which is capable of
> actually running, all the information necessary to make it run must be
> avaible to him, meaning there is no secrecy but just a certain level
> of obfuscation *and* the de-obfuscating code.
That's not what I mean. I mean that every public-key encryption system
can provably be broken with sufficient computing power. This is a
fundamental "vulnerability" in public-key encryption and it can be
proven that no public-key encryption system can be made that cannot be
broken by brute force.
The question is whether anyone can muster the amount of brute force
needed to break a given system.
Same here. You can prove any DRM system or licensing scheme can be
broken with sufficient force and cleverness. The question is whether
anyone can muster that amount of force and cleverness.
DS
| |
| Golden California Girls 2007-07-07, 10:11 pm |
| David Schwartz wrote:
> On Jul 6, 1:23 am, Rainer Weikusat <rweiku...@mssgmbh.com> wrote:
>
>
>
> That's not what I mean. I mean that every public-key encryption system
> can provably be broken with sufficient computing power. This is a
> fundamental "vulnerability" in public-key encryption and it can be
> proven that no public-key encryption system can be made that cannot be
> broken by brute force.
>
> The question is whether anyone can muster the amount of brute force
> needed to break a given system.
>
> Same here. You can prove any DRM system or licensing scheme can be
> broken with sufficient force and cleverness. The question is whether
> anyone can muster that amount of force and cleverness.
Much better than what you originally wrote because public key systems are public
by nature. You don't need a binary when all the algorithms are public anyway.
As long as Moore's law holds there are going to be a lot of secrets
embarrassingly reveled in the future.
| |
| Golden California Girls 2007-07-07, 10:11 pm |
| Seth7TS@gmail.com wrote:
> Hi,
> i need to increment a counter every time a software is launched(i
> would like to do a sort of trial version)...I have no idea how to hide
> it and where...
> can someone help me??
> thanks
>
> Seth
>
Screw the counter. Write a script to hard code the download time in the binary
on the fly and put in a test that disables it in x days. Use an installer
script to verify the clock on the system is reasonable or fail to install.
Check last access times, a pref's file and the like to be sure he doesn't try
and cheat by setting his clock backwards. You can't catch 100% of the cheats,
but print the current date and time on every output. Makes people loath to play
with the clock. Of course if your program depended on the clock being right ...
| |
| Måns Rullgård 2007-07-07, 10:11 pm |
| Golden California Girls <gldncagrls@aol.com.mil> writes:
> Seth7TS@gmail.com wrote:
>
> Screw the counter. Write a script to hard code the download time in
> the binary on the fly and put in a test that disables it in x days.
What's to stop me removing the check from the binary?
> Use an installer script to verify the clock on the system is
> reasonable or fail to install. Check last access times, a pref's
> file and the like to be sure he doesn't try and cheat by setting his
> clock backwards.
It's easy enough to hack the kernel to offset *all* time values
reported to a process. Applying the same offset to values returned by
gettimeofday(), stat() and a few other system calls makes it
impossible for the application to detect anything.
The only way to prevent someone running code is not giving it to them
in the first place.
--
Måns Rullgård
mans@mansr.com
| |
| Rainer Weikusat 2007-07-07, 10:11 pm |
| Måns Rullgård <mans@mansr.com> writes:
[...]
> The only way to prevent someone running code is not giving it to them
> in the first place.
One of the more irritating properties of people is that they don't
necessarily want to believe in the truth. So, while you are completely
right, there is no point in trying to convince someone who wishes
reality was different.
| |
| Måns Rullgård 2007-07-07, 10:11 pm |
| Rainer Weikusat <rweikusat@mssgmbh.com> writes:
> Måns Rullgård <mans@mansr.com> writes:
>
> [...]
>
>
> One of the more irritating properties of people is that they don't
> necessarily want to believe in the truth. So, while you are completely
> right, there is no point in trying to convince someone who wishes
> reality was different.
You are quite right. I still can't help trying once in a while.
--
Måns Rullgård
mans@mansr.com
| |
| Boltar 2007-07-07, 10:11 pm |
| On Jul 7, 5:47 pm, M=E5ns Rullg=E5rd <m...@mansr.com> wrote:
>
> It's easy enough to hack the kernel to offset *all* time values
> reported to a process. Applying the same offset to values returned by
Easy enough if you're a kernel hacker. Difficult or impossible for
99.999% of everyone else.
B2003
| |
| Rainer Weikusat 2007-07-07, 10:11 pm |
| Boltar <boltar2003@yahoo.co.uk> writes:
> On Jul 7, 5:47 pm, Måns Rullgård <m...@mansr.com> wrote:
>
> Easy enough if you're a kernel hacker. Difficult or impossible for
> 99.999% of everyone else.
All these nice people hanging out on the internet who are so much
against creating new things are really good in breaking existing
ones. And there are really many of them.
| |
| Måns Rullgård 2007-07-07, 10:11 pm |
| Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Trace: individual.net 8FfIANOQAxqn3Jo9zcmoggNhgILqiR2raDrLij4Z
kSVKbakCEp
Cancel-Lock: sha1:IHsHWZUReLvsDlhtWIw9qhb0ZwA= sha1:AbNvVWLf7rb1YymaMUBIlQOtwJg=
User-Agent: Gnus/5.1008 (Gnus v5.10.8) XEmacs/21.4.20 (Double Solitaire, linux)
Bytes: 2425
Xref: number1.nntp.dca.giganews.com comp.unix.programmer:179160
Rainer Weikusat <rweikusat@mssgmbh.com> writes:
> Boltar <boltar2003@yahoo.co.uk> writes:
>
> All these nice people hanging out on the internet who are so much
> against creating new things are really good in breaking existing
> ones. And there are really many of them.
If, by "things" you mean attempts at license enforcement mechanisms,
count me in as being against the creation any more of them. I'm not
against it because I'm afraid I won't be able to break them. I simply
consider the continuing battle a waste of time for both sides.
All such schemes are nothing but security by obscurity in one way or
another, and nothing that happens in a PC is obscure enough that it
can't be reverse engineered. There's a reason the more serious types
of protection use smartcards or USB dongles to hide the secrets.
These too can be cracked in theory, but doing so requires equipment
far more sophisticated (such as electron microscopes) than anyone is
likely to use for such purposes.
--
Måns Rullgård
mans@mansr.com
| |
| Golden California Girls 2007-07-08, 4:17 am |
| Måns Rullgård wrote:
> Golden California Girls <gldncagrls@aol.com.mil> writes:
>
>
> What's to stop me removing the check from the binary?
>
>
> It's easy enough to hack the kernel to offset *all* time values
> reported to a process. Applying the same offset to values returned by
> gettimeofday(), stat() and a few other system calls makes it
> impossible for the application to detect anything.
>
> The only way to prevent someone running code is not giving it to them
> in the first place.
>
I notice you didn't quote the part that counts, at least for a program that does
something useful. Put the date and time on all output. Games are another
matter. Cripple ware is the only choice for them.
And, why bother to hack the kernel? Isn't it just easier to set the clock back
in the first place? I just wonder how good a hack you are proposing anyway?
Let's compare the binary time with the binary mod time on that temp file the
process just created. Heck, read the entire file system for time values.
Checksum the program. If you find playing, overwrite that important data file
the program owns and needs to run. Sure we can play this game for a long time.
And no one has said you just can't download another copy!
The reason you lock a program is to make people who need it, pay for it. Once
the amount of work to hack around it is worth more than the selling price you
have done your job locking it.
Sure someone will hack around it. They never would buy it in the first place so
there is no lost revenue. The point of the lock isn't to be 100% effective.
The point is to maximize the revenue stream. The fly is having a hacked version
posted. That's why you have a team of lawyers on retainer.
| |
| Rainer Weikusat 2007-07-08, 8:05 am |
| Golden California Girls <gldncagrls@aol.com.mil> writes:
> Måns Rullgård wrote:
[...]
[color=darkred]
>
> I notice you didn't quote the part that counts, at least for a program
> that does something useful. Put the date and time on all output.
> Games are another matter. Cripple ware is the only choice for them.
>
> And, why bother to hack the kernel?
Because the kernel is the entity ultimatively controlling the machine
and no application running on an kernel that can be modified by an
'untrusted entity' stands any chance against it.
> Isn't it just easier to set the clock back in the first place? I
> just wonder how good a hack you are proposing anyway? Let's compare
> the binary time with the binary mod time on that temp file the
> process just created. Heck, read the entire file system for time
> values.
To determine what? Different files have differen timestamps associated
with them? Besides, I think you misunderstand part of this: If the
kernel has been modified to keep a particular application within 'a
fake time universe', this application will never be able to get a
correct reading of the time.
> The reason you lock a program is to make people who need it, pay for
> it.
No. The reason to 'lock' a program is that the person writing the code
is not willing to believe that anybody could be so honest to pay for
the program, just because that's what one would usually do when acquiring
things sold commercially and not paying is usually a felony. But if
you think all your users are criminals, anyway, what makes you so
certain that they will not have much more mundane means avaible of
'convincing' you that you should take special care of what they want?
NB: The question is rethorical. Another human habit is to project
their own, bad properties somewhat exaggerated into others. Which
roughly translates into 'the author of the software is the person who
would certainly commit this felony if he was in the position for doing
so'. Which leads to a more important question: Are you (any reader)
willing to trust someone with this particular mindset enough that you
would want to buy 'blackbox software' which at least has the potential
to harm you from him?
My personal answer to this question would be 'certainly not'.
> Once the amount of work to hack around it is worth more than the
> selling price you have done your job locking it.
It only needs to be cracked once and then just copied as needed,
meaning to 'amortized cost' of 'hacking around it' is zero.
| |
| Golden California Girls 2007-07-08, 7:06 pm |
| In-Reply-To: <87d4z35fhm.fsf@fever.mssgmbh.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <Y7- dnb02ju3slwzbnZ2dnUVZ_uSgnZ2d@championbr
oadband.com>
Lines: 58
X-Usenet-Provider: http://www.giganews.com
NNTP-Posting-Host: 216.165.224.6
X-AuthenticatedUsername: NoAuthUser
X-Trace: sv3- 4wznfUvukZD3P943cdT6pNgCNAgQ0D0carr09vBt
QgV8XY0rQTlRzB1QU+FzJWW0JOnTKVk+wHNXEaX!
2rCtqf2v4lsHl/Vx/ RRlTLJal3fE0mTBg67KL5NNC+c1OtF5SyAReiZbG
ZFzWWJ8WuLFtJblWSuL!EEiySaeOgep1QoMTu6+n
g4PJ/CzymO/TGjz3oCI=
X-Complaints-To: abuse@championbroadband.com
X-DMCA-Complaints-To: abuse@championbroadband.com
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.35
Bytes: 4487
Xref: number1.nntp.dca.giganews.com comp.unix.programmer:179173
Rainer Weikusat wrote:
> To determine what? Different files have differen timestamps associated
> with them? Besides, I think you misunderstand part of this: If the
> kernel has been modified to keep a particular application within 'a
> fake time universe', this application will never be able to get a
> correct reading of the time.
It doesn't matter if the application can read time correctly from the kernel if
the application can find a time stamp that is in the future from the time value
the kernel supplies that some other application that does get the correct time
used. Quite an impressive hack to change only some data read from the disk in
all the possible ways it could be read. Not saying it can't be done, but really
impressive. But that still doesn't solve the problem that the kernel is now
supplying a garbage input to the program so the output of the program is
garbage. I don't think there is a kernel hack to fix that!
>
> No. The reason to 'lock' a program is that the person writing the code
> is not willing to believe that anybody could be so honest to pay for
> the program, just because that's what one would usually do when acquiring
> things sold commercially and not paying is usually a felony. But if
> you think all your users are criminals, anyway, what makes you so
> certain that they will not have much more mundane means avaible of
> 'convincing' you that you should take special care of what they want?
BS. Reason is that it is an observable fact that a percentage of the human
population is criminal. Or it is your contention that every one in prison is
innocent? Or are you saying there is no need for passwords because no one would
try and break into your computer?!
> NB: The question is rethorical. Another human habit is to project
> their own, bad properties somewhat exaggerated into others. Which
> roughly translates into 'the author of the software is the person who
> would certainly commit this felony if he was in the position for doing
> so'. Which leads to a more important question: Are you (any reader)
> willing to trust someone with this particular mindset enough that you
> would want to buy 'blackbox software' which at least has the potential
> to harm you from him?
You are full of BS.
> My personal answer to this question would be 'certainly not'.
>
>
> It only needs to be cracked once and then just copied as needed,
> meaning to 'amortized cost' of 'hacking around it' is zero.
Then you are projecting that there is some community of people that you would
belong to that ...
Seems like you've backed yourself into a corner and can't find a way out.
| |
| Måns Rullgård 2007-07-08, 7:06 pm |
| Golden California Girls <gldncagrls@aol.com.mil> writes:
> Rainer Weikusat wrote:
>
> It doesn't matter if the application can read time correctly from the
> kernel if the application can find a time stamp that is in the future
> from the time value the kernel supplies that some other application
> that does get the correct time used. Quite an impressive hack to
> change only some data read from the disk in all the possible ways it
There is a limited set of system calls that return time values.
Adjusting these to stay within a given range is quite trivial.
Believe me, I've done it.
>
> BS. Reason is that it is an observable fact that a percentage of the
> human population is criminal. Or it is your contention that every one
> in prison is innocent? Or are you saying there is no need for
> passwords because no one would try and break into your computer?!
He is saying, and I am agreeing, that trying to enforce a license is
pointless. The honest people will pay even if there is no
enforcement, and the bad guys will be able to use the program for
free, even if you do try to stop them. All you've accomplished is
create extra work for yourself writing the code and extra hassle for
the honest users. The bad guys will first enjoy breaking the
protections, then use the program for free without further hassle.
--
Måns Rullgård
mans@mansr.com
| |
| Rainer Weikusat 2007-07-08, 7:06 pm |
| Golden California Girls <gldncagrls@aol.com.mil> writes:
> Rainer Weikusat wrote:
>
> It doesn't matter if the application can read time correctly from the
> kernel
Ok, please read the following sentence very slowly: The application
cannot 'read' anything outside of its own address space except by
going through the kernel. This means it is solely for the kernel to
decide what values this application will see and there is no way
around that.
[...]
> Quite an impressive hack to change only some data read from the disk
> in all the possible ways it could be read.
It would be much more impressive to build an application that can (at
run time) cope with every conceivabe on disk format of every
filesystem it could possibly encounter and which includes code to gain
the necessary privileges for raw device access for all possible
combinations of kernels and userlands. Impressive enough that writing
such an application would take significantly more time then doing
something actually productive instead.
On the other hand, assuming such an application as existing, the
kernel still knows which of its disk buffer may contain filesystem
timestamps and can still offset them.
For all practical purposes, it would be sufficient to just modify
everthing which returns timestamps. Which isn't very much.
>
> BS. Reason is that it is an observable fact that a percentage of the
> human population is criminal.
That is not an observable fact. But it doesn't contradict my statement
above, anyway.
>
> You are full of BS.
I didn't expect you do like this statement. But if I buy software from
you, I must put a certain trust in your personal integrity. And if you
are not willing to trust mine, why would I feel compelled to trust in
yours?
>
> Then you are projecting that there is some community of people that
> you would belong to that ...
I have just pointed out that your reasoning is fallacious and anything
beyond that is a lie you just made up because it suited you. See
comment about 'properties of people' above.
| |
| Gordon Burditt 2007-07-08, 7:06 pm |
| >> 'Public key encryption systems' depend on certain secrets remaining
>
>That's not what I mean. I mean that every public-key encryption system
>can provably be broken with sufficient computing power. This is a
>fundamental "vulnerability" in public-key encryption and it can be
>proven that no public-key encryption system can be made that cannot be
>broken by brute force.
The same is provable with most forms of private-key encryption, with the
one-time-pad being an exception.
>The question is whether anyone can muster the amount of brute force
>needed to break a given system.
>
>Same here. You can prove any DRM system or licensing scheme can be
>broken with sufficient force and cleverness. The question is whether
>anyone can muster that amount of force and cleverness.
DRM has a problem that public-key encryption does not: in DRM, the
*key is included* (unless it has to be gotten from the publisher's
servers over the net each time). It might be encrypted, but the
key to decrypt that must also be included. That makes it a *LOT*
less difficult to crack.
DRM needs to be able to decrypt the content for authorized users
in a reasonable amount of time. For example, it's not acceptable
if you put a DVD in a (authorized) DVD player and it takes 2 months
to *crack* the encryption before it starts playing. No, it needs
to already have the key and just *decrypt* the content with it.
It may be possible to let the DRM'd system run under an emulator
or debugger and just capture the data as it goes by (some DRM systems
try to detect if they are running under a debugger or emulator.
With a good enough emulator, this isn't possible). Sometimes you
can just fake the DRM out into thinking the serial number of your
box is that of an authorized box, and not bother with cracking the
128-bit encryption at all. Sometimes you can fake an "I am authorized"
certificate by changing the copy of the manufacturer's certificate
kept in the box to one of yours, then tell it that this box is
authorized signing with your certificate (to which you have the
private key). Sometimes (like with AACS recently), you just have to
fish the key out of the device firmware.
| |
| Golden California Girls 2007-07-08, 7:06 pm |
| Rainer Weikusat wrote:
> Golden California Girls <gldncagrls@aol.com.mil> writes:
>
> Ok, please read the following sentence very slowly: The application
> cannot 'read' anything outside of its own address space except by
> going through the kernel. This means it is solely for the kernel to
> decide what values this application will see and there is no way
> around that.
>
> [...]
>
>
> It would be much more impressive to build an application that can (at
> run time) cope with every conceivabe on disk format of every
> filesystem it could possibly encounter and which includes code to gain
> the necessary privileges for raw device access for all possible
> combinations of kernels and userlands. Impressive enough that writing
> such an application would take significantly more time then doing
> something actually productive instead.
Don't need that. Not at all. There are lots of places that are world readable
where time and date get stored. Think data files. Your kernel has to know
about all of them. Oh, if they aren't readable, then the program doesn't run
and the goal is accomplished.
And what's this crap about run time anyway? You have made a rash assumption
that the program is intended to run on every conceivable configuration and that
is was programed to do so without some sort of configuration process. And don't
assume that configuration is done on your machine.
I know you can't process this capitalistic truism that not selling to everybody
actually makes the profit bigger. The job is to maximize profit, not sales.
Selling to and supporting tiny specialized fractions costs way too much, so they
get left out. Think S-M-L.
> For all practical purposes, it would be sufficient to just modify
> everthing which returns timestamps. Which isn't very much.
Why not do it simple and just change the clock?
>
> That is not an observable fact. But it doesn't contradict my statement
> above, anyway.
It removes the assumption you made in making the statement. And it is
observable; all you need to do it use your eyes and see a crime, if you don't
want to trust someone else telling you of a crime they saw.
>
> I didn't expect you do like this statement. But if I buy software from
> you, I must put a certain trust in your personal integrity. And if you
> are not willing to trust mine, why would I feel compelled to trust in
> yours?
There you go making another rash assumption. Would buy a house that didn't have
locks? How about a car? Does the guard at the bank mean you won't put your
money there? How about the checker that totals your purchase rather than
letting you total it? How about the shoplifting scanners at the exit door? You
are so full of it. Get over yourself!
Now as for blackbox software I doubt you realize there is no other kind. Here
is why: How did you get the compiler on your machine to load up that open
source stuff? You had to get it in blackbox form. Everything you have done
since then has had to trust the blackbox. Never mind the BIOS! You are so full
of it. Get over yourself!
| |
| Golden California Girls 2007-07-08, 7:06 pm |
| Måns Rullgård wrote:
> Golden California Girls <gldncagrls@aol.com.mil> writes:
>
>
> There is a limited set of system calls that return time values.
> Adjusting these to stay within a given range is quite trivial.
> Believe me, I've done it.
Tell me all the places on the filesystem where a date is stored? Tell me again
how the kernel knows about all of them. Like the common ones the kernel had
nothing to do with storing. Oh that's right you'll just deny access to normally
world readable places, well then the program doesn't run and the goal is
accomplished.
>
> He is saying, and I am agreeing, that trying to enforce a license is
> pointless. The honest people will pay even if there is no
> enforcement, and the bad guys will be able to use the program for
> free, even if you do try to stop them. All you've accomplished is
> create extra work for yourself writing the code and extra hassle for
> the honest users. The bad guys will first enjoy breaking the
> protections, then use the program for free without further hassle.
So you are saying it is pointless to secure your property. Do you lock your
door? That's pointless, anyone with a saw can come through the wall.
You are both hung up on 100%. Get over it.
Locks keep honest people honest.
| |
| banansol@hushmail.com 2007-07-08, 7:06 pm |
| On Jul 8, 11:06 pm, Golden California Girls <gldncag...@aol.com.mil>
wrote:
> M=E5ns Rullg=E5rd wrote:
>
>
>
> Tell me all the places on the filesystem where a date is stored? Tell me=
again
> how the kernel knows about all of them. Like the common ones the kernel =
had
> nothing to do with storing. Oh that's right you'll just deny access to n=
ormally
> world readable places, well then the program doesn't run and the goal is
> accomplished.
>
>
>
>
>
> So you are saying it is pointless to secure your property. Do you lock y=
our
> door? That's pointless, anyone with a saw can come through the wall.
>
> You are both hung up on 100%. Get over it.
>
> Locks keep honest people honest.
Not at all! Quite the opposite in this case.
For example, I usually buy the music I listen to on CD.
Then one day I buy a CD (well, it claims to be one, but certainly
isn't)
and it won't play on my computer because of a stupid protection.
Thanks to that protection and their inability to trust a legitimate
customer
I got  and just downloaded all the songs from the Internet
instead.
So much for that lock, the only thing it did was to make me,
a honest person, into a pirate. I would not have done that if
the CD was a working one.
I totally agree with the others. No point in having such locks in
software.
| |
| Rainer Weikusat 2007-07-09, 4:16 am |
| Golden California Girls <gldncagrls@aol.com.mil> writes:
> Måns Rullgård wrote:
>
> Tell me all the places on the filesystem where a date is stored?
> Tell me again how the kernel knows about all of them.
Duh. Because the filesystem is part of the kernel.
> Like the common ones the kernel had nothing to do with storing.
Except providing the value to be stored and providing the code that
stored this value, no, absolutely nothing.
> Oh that's right you'll just deny access to normally world readable
> places,
Would you please be somewhat more specific as to what places you are
refering to? I don't think there are any.
[...]
>
> So you are saying it is pointless to secure your property.
No, that's what you would like to discuss instead of what actually had
been written.
> Do you lock your door? That's pointless, anyone with a saw can come
> through the wall.
It's really quite pointless. Anyone with the right tools and skills
can open you door in much less than a minute, no matter if its is
locked or not. But they tend to at least keep playing kids and nosey
middle-aged women living in the neighbourhood away.
The actual purpose of a door lock is to unambigously inform everybody
that the area behind the door is one where unauthorized people are not
supposed to be.
> Locks keep honest people honest.
That's a contradicitio in adiecto (the more modern term would be
'contradiction in terms'). If I walk along some street, I don't
try to randomly enter a house every here and there.
| |
| Rainer Weikusat 2007-07-09, 4:16 am |
| Golden California Girls <gldncagrls@aol.com.mil> writes:
> Rainer Weikusat wrote:
[...]
[color=darkred]
> I know you can't process this capitalistic truism that not selling to
> everybody actually makes the profit bigger. The job is to maximize
> profit, not sales. Selling to and supporting tiny specialized
> fractions costs way too much, so they get left out.
I do not quite understand how this relates to the topic. But
nevertheless, it's wrong. As long as you have the option of selling
something at a higher price than the one you bought it, it is possible
to make a profit doing so. That's the reason why tiny, specialized
companies exist, selling valuable goods without the overhead of an
army of overpaid sales representatives.
[...]
>
> Why not do it simple and just change the clock?
That would affect all applications on the system.
>
> It removes the assumption you made in making the statement. And it is
> observable; all you need to do it use your eyes and see a crime, if
> you don't want to trust someone else telling you of a crime they
> saw.
Do you understand the difference between 'person X has done some deed
I consider to be criminal', 'person X has been convicted of having
committed a felony' and 'person X "is criminal"'? You can observe the
first two but not the third.
>
> There you go making another rash assumption. Would buy a house that
> didn't have locks?
We weren't talking about houses.
> How about a car?
And neither of cars.
> Does the guard at the bank mean you won't put your money there?
There is no guard in my bank. And we weren't talking about banks.
> How about the checker that totals your purchase rather than letting
> you total it?
A large supermarket in the vicinity has started to offer
'self-service' cashpoints quite some time ago. This obviously saves
money because the customers 'serve' themselves, meaning, nobody needs
to be hired to serve them. I assume they lose some money this way,
but they probably lose some money at the ordinary cashpoints,
too. Apparently, what they save is more than what they lose (BTW,
this is the company that bought the relics of the failed WalMart
experiment to establish a supermarket chain in a country where it is
mostly illegal to not treat workers like actual people, namely, Real).
> How about the shoplifting scanners at the exit door?
We weren't talking about shop lifting. Judging from observation, the
main purpose of these things is to remind people who are 
enough to accidentally leave the store without paying something the
carry with them that they have forgotten to do so.
[...]
> Now as for blackbox software I doubt you realize there is no other
> kind.
I wasn't talking about 'blackbox software' as a topic of its own, but
about the need to trust people developing and selling blackbox
software and specifically, what makes me start to doubt that trusting
someone in this respect would be good idea. You can call this a pet
hypothesis of mine, but it comes from personal experience: People who
are not willing to believe that offers behave in basically lawful ways
because they want to are people that wouldn't themselves if not
forced.
I already had the mispleasure to have to write an 'encapsulation
daemon' for some network server which had been developed by a
contractor and where those contractor had conveniently included a
way to remotely disable the daemon and actually called at some point
in time, making threatening noises to involved third parties, trying
to disable the daemon at the same time. Insofar I have any influence
on decisions (which is of course very litte), I won't ever again.
> Here is why: How did you get the compiler on your machine to
> load up that open source stuff?
It has been compiled from sources I consider trustworthy by someone I
consider trustworthy unless proven otherwise.
| |
| David Schwartz 2007-07-09, 4:16 am |
| On Jul 8, 1:28 pm, gordonb.zp...@burditt.org (Gordon Burditt) wrote:
[color=darkred]
> The same is provable with most forms of private-key encryption, with the
> one-time-pad being an exception.
No, that is false. It is a unique property of public-key encryption.
For example, suppose I take a random 16-byte string and encrypt it
with a random AES key. If I give you the encrypted output, with
unlimited computing power, you still cannot determine for sure what
the key is or what the random 16-byte string I started with is.
This property really is unique to public-key encryption schemes. Or,
to put it another way, it is provable that every public-key encryption
scheme has this 'flaw'. In fact, it appears to be a fatal flaw until
you realize that it's possible to design systems where the flaw is
impossible to exploit *in* *practice*.
[color=darkred]
[color=darkred]
> DRM has a problem that public-key encryption does not: in DRM, the
> *key is included* (unless it has to be gotten from the publisher's
> servers over the net each time). It might be encrypted, but the
> key to decrypt that must also be included. That makes it a *LOT*
> less difficult to crack.
No, public key encryption schemes have the same problem. The public
key is included. This means, among other things, that an attacker can
always try every possible encryption path, find the one that produces
the same output, and be 100% sure he started with the same input.
In fact, when public key encryption was first described to me in
general terms way back when, I immediately realized that such a system
is provably impossible to be secure. It is only "practically
secure" (though I didn't realize that until it was demonstrated to
me).
> DRM needs to be able to decrypt the content for authorized users
> in a reasonable amount of time. For example, it's not acceptable
> if you put a DVD in a (authorized) DVD player and it takes 2 months
> to *crack* the encryption before it starts playing. No, it needs
> to already have the key and just *decrypt* the content with it.
Same for public key encryption. Both encryption and decryption must be
sufficiently rapid.
> It may be possible to let the DRM'd system run under an emulator
> or debugger and just capture the data as it goes by (some DRM systems
> try to detect if they are running under a debugger or emulator.
> With a good enough emulator, this isn't possible). Sometimes you
> can just fake the DRM out into thinking the serial number of your
> box is that of an authorized box, and not bother with cracking the
> 128-bit encryption at all. Sometimes you can fake an "I am authorized"
> certificate by changing the copy of the manufacturer's certificate
> kept in the box to one of yours, then tell it that this box is
> authorized signing with your certificate (to which you have the
> private key). Sometimes (like with AACS recently), you just have to
> fish the key out of the device firmware.
There will always be techniques to break any encryption or DRM scheme.
The question is whether there exists a scheme where such techniques
fail in practice. This is much harder to accomplish with a DRM scheme.
DS
| |
| Rainer Weikusat 2007-07-09, 7:06 pm |
| David Schwartz <davids@webmaster.com> writes:
> On Jul 8, 1:28 pm, gordonb.zp...@burditt.org (Gordon Burditt) wrote:
>
>
> No, that is false. It is a unique property of public-key encryption.
> For example, suppose I take a random 16-byte string and encrypt it
> with a random AES key. If I give you the encrypted output, with
> unlimited computing power, you still cannot determine for sure what
> the key is or what the random 16-byte string I started with is.
>
> This property really is unique to public-key encryption schemes.
Not at all. If you know the encryption key, you can determine the
original content that was encrypted by 'brute force' searching through
the space of all available messages until you find one which encrypts
to the same ciphertext. It's just that you don't need to bother with
this for symmetric encryption, because the same key is used for
encryption and decryption.
> Or, to put it another way, it is provable that every public-key
> encryption scheme has this 'flaw'.
This is not 'a flaw of public key encryption system' but a technical
property of 'encryption', namely, the encryption key can be used the
encrypt data. After all, that's its purpose.
> In fact, it appears to be a fatal flaw until you realize that it's
> possible to design systems where the flaw is impossible to exploit
> *in* *practice*.
Right. 'Encryption' looks 'fatally flawed' until you realize the brute
force searching through the space of possible messages is not
technically feasible, given a sufficiently strong algorithm.
[...]
>
> No, public key encryption schemes have the same problem. The public
> key is included. This means, among other things, that an attacker can
> always try every possible encryption path, find the one that produces
> the same output, and be 100% sure he started with the same input.
But with DRM, the _decryption key_ must be included, not the
_encryption key_. Meaning, all an attacker needs to do is to locate
this key (and the code using the key is avaible to him) and use it to
decrypt the data without brute-forcing anything.
[...]
>
> There will always be techniques to break any encryption or DRM
> scheme.
But a DRM scheme does not need to be broken, see above. It's like
'securing' access to something by locking the door, putting the key
below the doormat and only telling 'authorized people', but the door
is in a public place and anybody may watch those to his hearts
content.
| |
| David Schwartz 2007-07-09, 7:06 pm |
| On Jul 9, 2:20 am, Rainer Weikusat <rweiku...@mssgmbh.com> wrote:
> David Schwartz <dav...@webmaster.com> writes:
[color=darkred]
> Not at all. If you know the encryption key, you can determine the
> original content that was encrypted by 'brute force' searching through
> the space of all available messages until you find one which encrypts
> to the same ciphertext. It's just that you don't need to bother with
> this for symmetric encryption, because the same key is used for
> encryption and decryption.
You obviously completely missed my point! I could repeat it again in
more detail but it's really not worth it. The point is, a proof that
something must have a vulnerability of a particular type is only of
academic interest unless you can prove that vulnerability must be
practical.
[color=darkred]
> This is not 'a flaw of public key encryption system' but a technical
> property of 'encryption', namely, the encryption key can be used the
> encrypt data. After all, that's its purpose.
No, this is a flaw of public key encryption systems. It was, in fact,
one of the main reasons they were not used in the intelligence
community for a very long time after they were discovered. Private key
systems do not have to have this flaw.
[color=darkred]
> Right. 'Encryption' looks 'fatally flawed' until you realize the brute
> force searching through the space of possible messages is not
> technically feasible, given a sufficiently strong algorithm.
It's not just not technically feasible, it can be made literally
impossible. A one-time pad is the most obvious example of this. With
public key cryptosystems, however, it cannot be made literally
impossible. I can only be made not technically feasible.
The important thing to remember is that you cannot prove a system
impractical by demonstrating a flaw that is itself not practical.
[color=darkred]
[color=darkred]
> But with DRM, the _decryption key_ must be included, not the
> _encryption key_. Meaning, all an attacker needs to do is to locate
> this key (and the code using the key is avaible to him) and use it to
> decrypt the data without brute-forcing anything.
You can prove that anything you can do with one key you can do with
the other. It just isn't practical. Consider any operation you can
perform with the private key. you can perform the same operation with
the public key, simply try all inputs until you get the right output.
Of course, this isn't *practical*. Note that with private key systems,
it isn't even possible.
The point is, in practice, there is no difference between something
that is impractical and something that is impossible. At least, not
until it becomes practical.
So proving that it is possible to break any DRM system is not useful.
It is possible to break any PK system too.
> But a DRM scheme does not need to be broken, see above. It's like
> 'securing' access to something by locking the door, putting the key
> below the doormat and only telling 'authorized people', but the door
> is in a public place and anybody may watch those to his hearts
> content.
The exact same arguments were made against public key cryptosystems.
The public key can do anything the private key can do. You can prove
that. The public keys are in one-to-one correspondence with private
keys. You just can't get at the information hidden inside the public
key.
If I give you the product of two primes, I'm giving you the two
primes. You just can't *get* to them. It's precisely the same with
DRM. I'm giving you the key, you just can't get to it. At least, not
*easily*.
If we accepted your argument, we would have to reject all public key
encryption schemes.
DS
| |
| Rainer Weikusat 2007-07-09, 7:06 pm |
| David Schwartz <davids@webmaster.com> writes:
> On Jul 9, 2:20 am, Rainer Weikusat <rweiku...@mssgmbh.com> wrote:
>
>
>
>
> You obviously completely missed my point!
I was addressing your somewhat bizarre statements about 'public key
encryption'.
[...]
>
>
> No, this is a flaw of public key encryption systems.
It is pointless to call this 'a flaw'. 'Public key encryption' means
the encryption key is public (hence the name) and that means,
everybody can use it to encrypt something. That's the point of it
being 'public'.
> Private key systems do not have to have this flaw.
The proper opposites would be 'asymmetric encryption' (with different
keys used for encryption and decryption) and 'symmetric encryption'
(only one key used for both). Since the encryption key for a symmetric
cryptosystem can be used to decrypt encrypted messages, it must be
kept secret. Which leads to the chicken-and-egg-problem asymmetric
cryptosystems try to address, namely, that, in order to communicate
with someone using symmetric encryption, the secret key must be
communicated over a secure channel first. But if there is already a
secure channel, why not use that for communicating directly?
>
>
> It's not just not technically feasible, it can be made literally
> impossible. A one-time pad is the most obvious example of this.
A 'one-time pad' is the only example of this. All other cryptosystems
can be broken by doing a brute force search of the whole keyspace.
> With public key cryptosystems, however, it cannot be made literally
> impossible. I can only be made not technically feasible.
See above.
Having the encryption key available makes automated brute-forcing
easier, because a machine can decide when the correct decryption key
has been has been generated. But this still means that one will have
to test half of the keyspace on average. That's presumably one of the
reasons why keys for asymmetric cryptosystems are much larger than
those for symmetric cryptosystems.
[...]
>
>
> You can prove that anything you can do with one key you can do with
> the other. It just isn't practical. Consider any operation you can
> perform with the private key. you can perform the same operation with
> the public key, simply try all inputs until you get the right
> output.
Since the message space is literally inifinitvely large, that's beyond
'not practical', its ludicrous. A brute force attack would still
rather be targeted at searching the keyspace.
[...]
> The point is, in practice, there is no difference between something
> that is impractical and something that is impossible. At least, not
> until it becomes practical.
>
> So proving that it is possible to break any DRM system is not useful.
> It is possible to break any PK system too.
You are confusing yourself with your weird comparisons. Brute-force
attacks agains asymmetric cryptosystems are easier than brute-force
attacks against symmetric cryptosystem, provide one of the keys of the
asymmetric cryptosystem is avaible (say, because it is a 'public'
encryption key). But this is completely besides the point because
there is no reason to 'break' the encryption of a DRM system, neither
by bruteforce or cryptoanalisys because the key used to decrypt the
data must be available to the same person that is not supposed to be
able to decrypt it, because the DRM'ed content must be decrypted to be
perused.
[...]
[color=darkred]
> If we accepted your argument, we would have to reject all public key
> encryption schemes.
Feel free to do so if you really don't understand the difference.
| |
| David Schwartz 2007-07-09, 7:06 pm |
|
Rainer Weikusat wrote:
> David Schwartz <davids@webmaster.com> writes:
[color=darkred]
> It is pointless to call this 'a flaw'. 'Public key encryption' means
> the encryption key is public (hence the name) and that means,
> everybody can use it to encrypt something. That's the point of it
> being 'public'.
However, the public key can, provably, also be used for decryption.
[color=darkred]
> The proper opposites would be 'asymmetric encryption' (with different
> keys used for encryption and decryption) and 'symmetric encryption'
> (only one key used for both). Since the encryption key for a symmetric
> cryptosystem can be used to decrypt encrypted messages, it must be
> kept secret. Which leads to the chicken-and-egg-problem asymmetric
> cryptosystems try to address, namely, that, in order to communicate
> with someone using symmetric encryption, the secret key must be
> communicated over a secure channel first. But if there is already a
> secure channel, why not use that for communicating directly?
Because the secret channel is only intermittently available.
[color=darkred]
> A 'one-time pad' is the only example of this. All other cryptosystems
> can be broken by doing a brute force search of the whole keyspace.
No, that is not true. Maybe you're not reading what I wrote, but I
already addressed this point.
Suppose I take a random 16-byte message and encrypt it with a random
128-bit AES key. With the encrypted output and all the computing power
in the world, you could not determine the message.
[color=darkred]
> See above.
You are really not listening to what I am saying.
[color=darkred]
[color=darkred]
> Since the message space is literally inifinitvely large, that's beyond
> 'not practical', its ludicrous. A brute force attack would still
> rather be targeted at searching the keyspace.
Right, that's my point. Simply proving that an attack is possible in
principle is insufficient. It is still possible that the attack can be
"ludicrous" from a practical perspective.
[color=darkred]
> You are confusing yourself with your weird comparisons. Brute-force
> attacks agains asymmetric cryptosystems are easier than brute-force
> attacks against symmetric cryptosystem, provide one of the keys of the
> asymmetric cryptosystem is avaible (say, because it is a 'public'
> encryption key). But this is completely besides the point because
> there is no reason to 'break' the encryption of a DRM system, neither
> by bruteforce or cryptoanalisys because the key used to decrypt the
> data must be available to the same person that is not supposed to be
> able to decrypt it, because the DRM'ed content must be decrypted to be
> perused.
You are trying to take my analogy too far. My point is not that DRM is
as secure as public key cryptosystems. My point is that your
particular argument that DRM is not secure equally well applies to
public key cryptosystems.
[color=darkred]
[color=darkred]
> Feel free to do so if you really don't understand the difference.
No, I will instead reject your argument. You must demonstrate that the
attacks are *practical*, not just possible.
DS
| |
| Rainer Weikusat 2007-07-09, 7:06 pm |
| David Schwartz <davids@webmaster.com> writes:
> Rainer Weikusat wrote:
[...]
>
>
> You are trying to take my analogy too far. My point is not that DRM is
> as secure as public key cryptosystems. My point is that your
> particular argument that DRM is not secure equally well applies to
> public key cryptosystems.
I have not written that 'neither DRM nor public key cryptosytems are
secure' (that would be your heavy simplification of the matter) but
that
a) breaking an asymmetric cryptosystem with one of the keys
and a message encrypted with this key available by brute
force search of the key space is easier than breaking a
symmetric cryptosystem of comparable key size because
'success' can be determined by a machine.
b) DRM 'encryption' is useless, because the decryption key of
the DRM scheme must be available to the very people supposed
to be prevented from decrypting the content, because to use
this content, they must decrypt it first.
These are two wildly different things and summarizing both as
'something could be done against it' does not accurately reflect these
differences.
There is a reason why CSS was broken by three random people, while the
EFF had to come up with custom hardware with a USD 200.000 price tag
to break DES (and the reason is not that 'CSS' was an asymmetric
cryptosystem).
| |
| David Schwartz 2007-07-10, 8:06 am |
| On Jul 9, 12:51 pm, Rainer Weikusat <rweiku...@mssgmbh.com> wrote:
> I have not written that 'neither DRM nor public key cryptosytems are
> secure' (that would be your heavy simplification of the matter) but
> that
> a) breaking an asymmetric cryptosystem with one of the keys
> and a message encrypted with this key available by brute
> force search of the key space is easier than breaking a
> symmetric cryptosystem of comparable key size because
> 'success' can be determined by a machine.
The point is that any public key encryption system can be broken by
machine. They are all insecure if proving that there is a way to break
them is sufficient. However, that is not sufficient, you must also
show that the way to break them must always be practical. If it can be
made impractical, the scheme is secure.
> b) DRM 'encryption' is useless, because the decryption key of
> the DRM scheme must be available to the very people supposed
> to be prevented from decrypting the content, because to use
> this content, they must decrypt it first.
This proves that they can theoretically break it. They have the key in
context A, therefore they might be able to use it in context B. But
this prove does not show that it is *practical* for them to do so.
As a simple counter-argument, consider a tamper-proof physical
hardware device. It has a private key and a public key in it. It is
constructed that if you input a message signed by the private key
corresponding to its public key, it will decrypt the message with the
private key.
The key to the scheme is that a person with such a device must not be
able to decrypt messages not signed, however, the device has the key
to do the decryption. It comes down to how tamper-proof the device is.
There's a huge market in such tamper-proof devices, and it would come
as quite a surprise to thousands of security professionals that such
devices are "worthless".
Just because you have the key and can use it context A does not mean
it is *practical* for you to extract the key and use it in context B.
> These are two wildly different things and summarizing both as
> 'something could be done against it' does not accurately reflect these
> differences.
>
> There is a reason why CSS was broken by three random people, while the
> EFF had to come up with custom hardware with a USD 200.000 price tag
> to break DES (and the reason is not that 'CSS' was an asymmetric
> cryptosystem).
I agree, but that doesn't save your argument. Your argument does not
prove that it is impossible to make this vulnerability impractical.
There are plenty of analogous cases where it has proven to be possible
to make exactly this type of vulnerability impractical.
In fact, the IBM 4758 does precisely what you claim is "useless". It
gives a person a key but makes it practically impossible for them to
use it except as the security policy allows. (And to some extent
proves that this is difficult as there have been vulnerabilities found
and fixed in these products.)
DS
| |
|
| David Schwartz wrote:
> Rainer Weikusat wrote:
<snip>
David, Rainer,
You seem to be in disagreement over a cryptography-related topic.
I would therefore strongly suggest that you add sci.crypt to the list
of newsgroups, in order to give cryptography enthusiasts a chance to
chime in, should they choose to do so.
Regards.
| |
| Rainer Weikusat 2007-07-10, 8:06 am |
| David Schwartz <davids@webmaster.com> writes:
> On Jul 9, 12:51 pm, Rainer Weikusat <rweiku...@mssgmbh.com> wrote:
>
>
> The point is that any public key encryption system can be broken by
> machine. They are all insecure if proving that there is a way to break
> them is sufficient. However, that is not sufficient, you must also
> show that the way to break them must always be practical. If it can be
> made impractical, the scheme is secure.
Is there particular reason why you keep repeating this? Except that it
nicely illustrates your confusion regarding the topic? All
cryptosystems using a non-unique, short key can be broken by
applying a sufficient effort of 'brute force' to the problem. They are
considered to be 'secure' if the average 'force effort' that is
needed is large enough that it is deemed to be not feasible to
actually do this. Usually, this means that you have to search the
keyspace until you are lucky, because no short cuts are presently
known.
A brute force attack against an asymmetric cryptosystem, assuming that
one of the keys is known, with, for example, a key size of 1024 bit,
will 'on average' have determined the other key after having tried
2^512 random 1024 bit keys.
But this is completely besides the point and only serves to confuse
the issue.
>
> This proves that they can theoretically break it.
Which part of 'if I have the key, I don't need to break into the
cipher' constantly manages to escape your attention? [Or, perhaps more
correctly, which part of this simple truth do you try to smuggle past
the attention of 'some third parties' by piling unrelated numbers on
top of it?].
[...]
> There's a huge market in such tamper-proof devices, and it would come
> as quite a surprise to thousands of security professionals that such
> devices are "worthless".
Insofar it is the function of this 'tamper proof' device to decrypt
data, so that it can be used by people who are supposed to be
prevented from decrypting the data, they are worthless. It is not
necessary to 'tamper' with anything here, because the keys used for
decryption and even a special-purpose computer performing the
decryption are there and there intended purpose is to decrypt the
supposed to be protected data, which is a a process after which it
isn't protected anymore. Which is technically necessary, because it is
supposed to be consumed by an input device not capable of decrypting
it on its own. Like a human ear. At some point in time during this
process, the unencrypted, digital signal corresponding with the
supposed-to-be protected content is used to drive something capable of
generating sound. End of 'hyperprotecting anaconda sweat'.
Additionally, it may even be possible to break into the supposed to be
tamper-proof device and just extract the supposed-to-be secret
information. But this is a completely different issue.
| |
| David Schwartz 2007-07-10, 8:06 am |
| On Jul 10, 3:16 am, Rainer Weikusat <rweiku...@mssgmbh.com> wrote:
> Is there particular reason why you keep repeating this?
Yes, it is an argument of precisely the type you are making, and it is
obviously invalid. Your argument is equally invalid, just less
obviously so.
> Except that it
> nicely illustrates your confusion regarding the topic? All
> cryptosystems using a non-unique, short key can be broken by
> applying a sufficient effort of 'brute force' to the problem.
That is not true. As I've explained at least three times now. You
cannot, for example, break AES in this manner. Even with all the brute
force in the world, you would have no way to know when you had tried
the correct key.
> They are
> considered to be 'secure' if the average 'force effort' that is
> needed is large enough that it is deemed to be not feasible to
> actually do this. Usually, this means that you have to search the
> keyspace until you are lucky, because no short cuts are presently
> known.
In other words, the attack must be practical, not just possible in
theory. Demonstrating an attack unavoidably possible in theory is not
sufficient to show that the attack is unavoidable in practice. Yet
this is what you keep claiming.
> A brute force attack against an asymmetric cryptosystem, assuming that
> one of the keys is known, with, for example, a key size of 1024 bit,
> will 'on average' have determined the other key after having tried
> 2^512 random 1024 bit keys.
>
> But this is completely besides the point and only serves to confuse
> the issue.
That is the point. You can "prove" that all asymmetric cryptosystems
can be "broken" in this way. But the proof is completely meaningless
because even though it shows the vulnerability is always there in
principle, it does not show that it is possible in practice.
This distinction is very obvious to a knowledgeable person who
understands public-key encryption systems. But in the early days of
such systems, arguments just like these convinced people that such
systems could never be secure. (And in fact delayed their adoption.)
At the time, no algorithms were known that would create the difficulty
of implementing the break in practice that is so obvious to you now.
Some people refrained from researching or adopting public-key
cryptosystems precisely because this proof *was* so convincing at the
time.
We may analogously be in the early days of DRM. And your proof that an
attack is always possible in principle may analogously deter people
from developing the algorithms that will make it obvious in later
decades that your argument is incorrect.
[color=darkred]
[color=darkred]
> Which part of 'if I have the key, I don't need to break into the
> cipher' constantly manages to escape your attention? [Or, perhaps more
> correctly, which part of this simple truth do you try to smuggle past
> the attention of 'some third parties' by piling unrelated numbers on
> top of it?].
This same argument was used, incorrectly, against public-key
cryptosystems in the early days. Nobody at the time could imagine that
an encryption scheme could be both irreversible and reversible based
on knowledge of *another* key. Perhaps some analogous trapdoor exists
for DRM, although as you have correct showed, an attack will always be
possible in theory.
> [...]
>
[color=darkred]
> Insofar it is the function of this 'tamper proof' device to decrypt
> data, so that it can be used by people who are supposed to be
> prevented from decrypting the data, they are worthless. It is not
> necessary to 'tamper' with anything here, because the keys used for
> decryption and even a special-purpose computer performing the
> decryption are there and there intended purpose is to decrypt the
> supposed to be protected data, which is a a process after which it
> isn't protected anymore. Which is technically necessary, because it is
> supposed to be consumed by an input device not capable of decrypting
> it on its own. Like a human ear. At some point in time during this
> process, the unencrypted, digital signal corresponding with the
> supposed-to-be protected content is used to drive something capable of
> generating sound. End of 'hyperprotecting anaconda sweat'.
This proves the attack possible, not practical.
> Additionally, it may even be possible to break into the supposed to be
> tamper-proof device and just extract the supposed-to-be secret
> information. But this is a completely different issue.
This again process the attack possible, not practical.
We could have had precisely this same argument about the impossibility
of secure public-key encryption systems days before DH was discovered.
You would have advised me not to waste my time looking for such an
algorithm because you can prove it can't possibly be secure.
I notice a strange common thread in my disagreements with you -- you
seem to insist on repeating the mistakes of the past no matter how
clearly they are pointed out to you. It is an error to assume that a
proof that an attack is possible means the attack cannot be made
impractical. Why do you insist on repeating this error?
DS
| |
| Rainer Weikusat 2007-07-10, 8:06 am |
| David Schwartz <davids@webmaster.com> writes:
> On Jul 10, 3:16 am, Rainer Weikusat <rweiku...@mssgmbh.com> wrote:
>
> Yes, it is an argument of precisely the type you are making, and it is
> obviously invalid.
No it is not 'an argument of precisely the type I am making', mainly,
because it is not an argument at all, but just a persistent
misunderstanding regarding cryptoanlytical techniques and (assumed)
security of encryption algorithms.
>
> That is not true. As I've explained at least three times now.
> You cannot, for example, break AES in this manner. Even with all the
> brute force in the world, you would have no way to know when you had
> tried the correct key.
http://cryptome.org/cracking-des/cracking-des.htm
-----------
A cryptographic algorithm is considered strong if:
1. There is no shortcut that allows the opponent to recover
the plain text without using brute force to test keys until
the correct one is found; and
2. The number of possible keys is sufficiently large to make
such an attack infeasible.
-----------
http://people.csail.mit.edu/rivest/bsa-final-report.txt
[NB: I didn't knew this by the time I wrote it down]
Just typing 'brute force attack' into a Google search box will lead to
many other ressources, especially, regarding sucessful brute-force
attacks against symmetric chipers with 'short' key lengths.
I am too lazy to dig through the nth repetition of the same crap
again, sorry.
| |
| Rainer Weikusat 2007-07-10, 8:06 am |
| Spoon <root@localhost> writes:
> David Schwartz wrote:
>
>
> <snip>
>
> David, Rainer,
>
> You seem to be in disagreement over a cryptography-related topic.
No, we are in disagreement about the possibility of building a working
CD-player that prevents people from accessing the information it turns
into audible sounds despite it is providing access to it (otherwise,
it wouldn't be working).
| |
| David Schwartz 2007-07-10, 7:07 pm |
| On Jul 10, 5:42 am, Rainer Weikusat <rweiku...@mssgmbh.com> wrote:
[color=darkred]
> No it is not 'an argument of precisely the type I am making', mainly,
> because it is not an argument at all, but just a persistent
> misunderstanding regarding cryptoanlytical techniques and (assumed)
> security of encryption algorithms.
Yet it was believed to be a valid argument for many years. It wasn't
until after the discovery of DH, and in some cases well after that,
that it was recognized that the argument was invalid. A theoretical
vulnerability that can be made impractical is not a true
vulnerability.
The exact same thing is true of your argument. It demonstrates a
theoretical vulnerability but does not prove that the vulnerability
cannot be made impractical. Your argument is invalid for the same
reason this one is.
[color=darkred]
[color=darkred]
> http://cryptome.org/cracking-des/cracking-des.htm
> -----------
>
> A cryptographic algorithm is considered strong if:
>
> 1. There is no shortcut that allows the opponent to recover
> the plain text without using brute force to test keys until
> the correct one is found; and
>
> 2. The number of possible keys is sufficiently large to make
> such an attack infeasible.
>
> -----------http://people.csail.mit.edu/rivest/bsa-final-report.txt
> [NB: I didn't knew this by the time I wrote it down]
By these criteria, DRM may or may not be strong, depending upon
whether it is easier to get the key out of the DRM system or to brute
force the key. In other words, it just comes right back to whether or
not the attack you describe is practical.
> Just typing 'brute force attack' into a Google search box will lead to
> many other ressources, especially, regarding sucessful brute-force
> attacks against symmetric chipers with 'short' key lengths.
Yet it is trivial to make these attacks impossible. With RSA, for
example, if the input message is only a single byte, no brute force
attack is possible.
> I am too lazy to dig through the nth repetition of the same crap
> again, sorry.
If you would simply present some argument why it is impossible to make
the attack you claim makes DRM worthless impractical, the argument
would be over. But the history of public-key cryptosystems shows that
people often erroneously accept arguments that prove vulnerabilities
are possible when later evidence shows those vulnerabilities can be
made impractical.
It's funny that you and I always seem to get to this same issue. You
seem to militantly insist on repeating mistakes over and over.
DS
| |
| GeorgPeter@gmx.at 2007-07-10, 7:07 pm |
| On 5 Jul., 11:53, Seth...@gmail.com wrote:
> Hi,
> i need to increment a counter every time a software is launched(i
> would like to do a sort of trial version)...I have no idea how to hide
> it and where...
Do you want to have just a counter or is it really necessary to
have a secret counter?
Georg Peter
|
|
|
|
|