Cryptography-Digest Digest #145, Volume #10 Tue, 31 Aug 99 00:13:02 EDT
Contents:
Re: 512 bit number factored (SCOTT19U.ZIP_GUY)
Re: Can I export software that uses encryption as copy protection? ("Trevor Jackson,
III")
Re: What if RSA / factoring really breaks? ("David J Whalen-Robinson")
Re: On employing message-decoys ("rosi")
Re: 512 bit number factored (DJohn37050)
Re: Newbiehelp (JC)
Re: public key encryption - unlicensed algorithm ("rosi")
Re: public key encryption - unlicensed algorithm (David A Molnar)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: 512 bit number factored
Date: Tue, 31 Aug 1999 00:31:20 GMT
In article <7qefvl$1is$[EMAIL PROTECTED]>, Bob Silverman <[EMAIL PROTECTED]> wrote:
>In article <[EMAIL PROTECTED]>,
> Anton Stiglic <[EMAIL PROTECTED]> wrote:
>> Bob Silverman wrote:
>
>> >
>> > > 4. Algorithmic breakthroughs are possible. RSA 512 was thought >>totally
> unbreakable just a few years ago.
>> >
>> > > Don Johnson
>> > >
>> > More deceit and lies.
>> >
>>
>> [here he goes again!]
>>
>> >
>> > If, by "a few years ago", you mean 15 years, I will agree.
>> >
>>
>> of cours. The inventors of RSA gave out a challenge, they beleived that
>> factoring
>> would have taken _much_ longer time (be it impossible). (was that in a
>> Scientific
>> American journal of something...?).
>> Why use the words "deceit and lies" for this statement, when we all know it
>> is
>> true!
>
>Your facts are confused.
>
>The RSA-129 factoring challenge dates from a 1977 article.
>This pre-dates both the quadratic sieve and parallel factoring
>methods.
>
>
>I would call 22 years (1999-1977) more than 'a few years'.
>
>Secondly, as Ron himself has admitted, when he made the
>claim about '40 quadrillion years' for RSA-129, he had forgotten
>about the continued fraction algorithm. (invented in 1970). Ron
>had only considered trial division when he made this now
>famous and mistaken estimate. Even back in 1977 it would
>not have taken anywhere close to what Ron had estimated.
>(But it was legitimately out of reach then)
>
>Thirdly, while Ron is a world class cryptographer, he is not
>an expert on factoring algorithms. Nor did he consult with anyone
>when he made his 1977 quote.
I love the excuses people make. I say that is estame of 40 quadriillon
years was a little off. I think people should use the largtest keys they
can. istead of whining that the guess where honest. In point of fact
the guessed where a lie. For 2 reasons. They know knowledge advances
and breaking tecniques advacne. So any estimate beyond a few years
is a LIE. So use the largest key that you can comfortable use on your
machine instead of something the "experts" say will be safe. As world
war II proves the "experts" are worng. These get easyer with time.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
Date: Mon, 30 Aug 1999 20:57:09 -0400
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Crossposted-To: misc.legal.computing
Subject: Re: Can I export software that uses encryption as copy protection?
Eric Lee Green wrote:
> "Trevor Jackson, III" wrote:
> > Eric Lee Green wrote:
> > > it is physically on my disk. I don't even necessarily have to
> > > replay it. The first major program that I ever wrote was a commenting
> > > disassembler (i.e., you could add comments that went with various memory
> > > addresses), and then I could patch the binary directly on the disk prior
> > > to loading it.
> >
> > OF COURSE it's easy to patch a disk image. That's like solving a monoalphabetic
>cipher.
> > Trivial. Your success in patching programs is to your credit, but solving easy
>problems
> > does not support your contention that all problems are as easy to solve.
>
> All I'm noting is that encrypting the license key portions of your
> program is going to be more of a nuisance factor than anything else.
> It'll stop a few script kiddies at best, but "real" crackers will view
> it as a challenge and swiftly strip out the license portion of your
> code.
>
> > > They failed. If I have physical access to your
> > > > > software, I can load it into a binary debugger, trace its execution, and
> > > > > 'break' it.
> >
> > You might be able to, but it wouldn't be as simple as the sentence above. For
>instance,
> > if you are tracing from point to point with breakpoints, you'll have a bit of
>trouble
> > with the code that stomps the breakpoint trap vector and breakpoint trap handler.
>If you
> > are single stepping, you'll have a bit of trouble with the code that stomps the
>trace
> > trap vector and handler.
>
> Yawn. That's the code you binary-patch a "JMP" around. I know (former)
> crackers who used to do that in their sleep. (Or at least at a time of
> night when they SHOULD have been asleep!).
Yup. And then you find the app silently fails to operate because the footprint of the
stomp is
necessary to its continued functionality.
> > > It requires enormous hardware support only if it's not on your disk
> > > drive. As I mentioned, I can disassemble it while it's not running, and
> > > patch the binary directly to put a breakpoint after the end of the
> > > decryption routine that jumps into the debugger.
> >
> > If the app fights the debugger hard enough your patch effort will be larger than
>the
> > effort required to write the application from scratch. It will still be possible
>to
> > crack the application, but it wouldn't be sane to do so unless you wanted bragging
> > rights.
>
> Congratulations, you just discovered that crackers aren't sane! The more
> effort it takes, the more prestige that crackers get by breaking it, and
> the more they'll trumpet the fact and feature your product on "warez"
> sites.
No. You are assuming the software, once stripped of its protection, can be executed
on any
machine. That is trivially false.
> > > Not on most modern operating systems. For example, Unix runs all
> > > programs in a virtual machine,
> >
> > Really. How many versions of Unix have you used?
>
> Let's see. BSD 4.2, BSD 4.3, FreeBSD, OpenBSD, Sys V.2, Sys V.3, Sys
> V.4,
> SunOS, HPUX, Solaris, Linux, Xenix, Pyramid OSx, SCO Unix... probably a
> couple more that I haven't recalled at the moment, since I've been
> "doing" Unix since 1985. I currently work for a Unix software house that
> has ports to every major Unix platform, most of which we have in our
> porting lab, and which I refer to regularly in order to, e.g., make sure
> my software works properly on both little-endian and big-endian
> machines.
Then you should know the proper definition of virtual machine. BSD didn't have a
virtual
machine (except fot he embedded PDP-11 mode on VAXen), it had virtual memory.
Privilege levels
do not constitute a virtual machine. A virtual machine is privilege levels PLUS an
emulator
that makes the kernel and/or supervisor -mode instructions appear to operate.
> I think you are confusing a virtual machine with a virtualized CPU. Unix
> programs run on a virtual machine that consists of: memory (and only
> memory that it has been allocated by the OS), and a "trap" call to enter
> the operating system. That's pretty much it.
No, that's pretty much an abstract machine not a virtual machine. A virtual machine
is an
abstract machine that is enforced by the hardware.
> If a Unix program attempts
> to do things like, e.g., set interrupt vectors, or directly access a
> hard drive controller, an exception will be generated and the execution
> of the program suspended (what the OS does then depends on what handlers
> have been set up but most probably you will NOT be setting an interrupt
> vector or writing bytes to the hard drive). Thus you obviously cannot
> run an operating system within the Unix virtual machine, since it is not
> a virtualized CPU but rather a simplified pseudo-machine that just
> happens to have a VERY intelligent "trap" call (grin).
No, you are mangling the terminology. There are three things involved. First is
privilege
level, second is virtual memory, and third is virtual machine. You are using the term
virtual
machine incorrectly. Privileged instructions simply require the aquisition of the
permission.
And there are always ways for a well-behaved program to obtain the necessary
permissions.
> > Most don't use virtual machines because
> > virtual machines became common far later than Unix did.
>
> Err, VM/CMS? Multics? Hmm? (I don't know about VM/CMS, but Multics
> *certainly* precedes Unix). It doesn't really matter, because it appears
> that we are talking about different things. You are talking about a
> virtualized CPU, and I am talking about the virtual memory/system call
> exception scheme that every major Unix variant uses as its virtual
> machine (the only ones that I am aware of that do not are certain older,
> cruder Xenix implementations, and various academic "toys" like Minix).
The systems you are talking about have virtual memory not virtual machines. Systems 6
& 7
didn't have anything like virtual machines. System III didn't either. System V
didn't either.
> > Of the versions that do use virtual machines, there are always ways to escape the
> > virtualization.
>
> If you are running SUID root then you can request specific i/o ports and
> such. But for normal programs you do not have that option.
Is all of your experience on Unix? There are legacy systems running applications
under up to
five layers of emulation. Some of those apps were written in the 50s!
> > As the attacker you enjoy the attackers fundamental advantage of selecting the
>point of
> > attack, where the defender, the author of the applicaiton, has to defend
>"everywhere".
> > This fact does lead to a dismissal of defense as a concept.
Oops. I was typing too fast. I stated the opposite of what I intended.
--> The attacker's advantage does not lead to a dismissal of defense as a concept.
By making it arbitrarily difficult to "crack" an application I can exclude an
arbitrarily
large fraction of users from "cracking" the app. That fraction will always be less
than one,
but I can get unreasonably close.
> Thank you. Actually, I think it does not rule out defense as a concept
> but, rather, defense against crackers as a concept. A certain amount of
> protection will keep out the script kiddies. Just don't overestimate
> what can be done on a defensive basis against a detirmined cracker.
We will never agree upon this because you are simply asserting your conclusion as fact.
I am not overestimating the defensive capability. I have a reasonable amount of
experience
with diddling binaries, and also some experience selling software (games). At one
time I was
selling a package to the public with a retail price of over $800 (mid '80s $). The
fact that
the package included no hardware assist (dongle, etc.) got earned it criticism similar
to
yours. And some publicly launched attacks by people who claimed, like yourself, to be
experienced crackers.
One person actually called me up and confessed that he had successfully penetrated the
outer
(polite) layer of the app, and had had so much difficulty that he was afraid to beat
on the
inner (less than polite) layers. And could he have a licensed copy?
With enough effort that app could have been cracked. But it would have taken a
substantial
fraction of the effort required to implement the whole thing.
> > > Cryptographic systems can only secure communications. They cannot stop
> > > an attacker from viewing the plaintext by "tapping" the decryption
> > > engine. Given physical access to the decryption engine, it can be rigged
> > > to spit out the plaintext to me at the same time that you view it.
> > > Without understanding this, you will never be able to create a secure
> > > cryptographic system.
> >
> > If you can undetectably "tap" the decryption engine you can certainly obtain the
> > plaintext. If you cannot the rest of your argument becomes moot.
>
> Correct. I'm just pointing out that there's a number of ways to
> undetectably "tap" the decryption engine on most modern operating
> systems.
Trivially false.
Virtual memory gains you nothing. In fact playing games with virtual addresses is a
typical
defensive gambit.
Privilege level also gets you little. It's too easy to test for the presence of a
debugger
anywhere on the system and determine the target app. If the target app is itself the
debugger
will become the debugee.
> > All such defensive systems have to be justified in terms of cost/benefit. I'll
>take your
> > word for it that the cost of more "hardening" of your code is not justified. But
>that
> > has nothing to do with the possibility of such hardening being useful.
>
> Granted. It'll keep out the script kiddies and casual browsers. But as
> far as hard-core crackers, it'll just be another challenge for them to
> boast about.
You are still assuming that "anything" can be cracked. With infinite resources that is
correct. With finite resources it is false.
> Given that the simplest of authentication schemes will suffice to give
> the script kiddies fits, I made a cost-benefit analysis and decided that
> further obfuscation was not necessary (don't get me wrong, it's a
> cryptograhically strong license information authentication scheme, but
> any detirmined cracker with a binary debugger and binary editor could
> crack it). My boss, who got his start in a similar way, agrees, saying
> "the kind of people who can defeat what you've done aren't going to buy
> our product anyhow."
Sounds like a reasonable decision.
------------------------------
From: "David J Whalen-Robinson" <[EMAIL PROTECTED]>
Crossposted-To: alt.math,sci.math
Subject: Re: What if RSA / factoring really breaks?
Date: Mon, 30 Aug 1999 11:21:30 -0400
> Also, a demonstration that cannot be reproduced is not very convincing.
RSA could make another number 4048 bits long.
The person could then post the factorization that week, if the new method
was
really truely that fast.
You are right, though. People would want proof, and not everyone would
believe it.
The person would have to be careful, or somebody would say
"Here crack this key as proof", and use the person to crack a key.
>
> John Savard
------------------------------
From: "rosi" <[EMAIL PROTECTED]>
Subject: Re: On employing message-decoys
Date: Mon, 30 Aug 1999 21:56:15 -0400
Mok-Kong Shen wrote in message <[EMAIL PROTECTED]>...
[... etc. ...
>
>It is an unstated (my apology!) assumption of mine that one is using
>a common type of symmetric algorithm where the key length cannot be
>changed by the user. With a variable key length, or more generally a
>parametrized algorithm, one can of course very easily render the
>cracking time of a single message far beyond the capability of the
>analyst. I use to puzzle why user choosable parametrized algorithms
>appear never have been favoured in major symmetric crypto system
>designs todate.
>
>M. K. Shen
Dear Mok-kong,
Just a word of thanks.
--- (My Signature)
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: 512 bit number factored
Date: 31 Aug 1999 01:48:53 GMT
The counter to using the largest key possible is performance and
interoperability. Some constrained devices can only use smaller keys with
acceptable performance. Security is fine as long as it does not impede what
one wants to do! And if someone else can only handle smaller keys, then I must
also to talk to them. So a goal is to find a key that is large enough to not
attack and small enough for good performance.
Don Johnson
------------------------------
From: JC <[EMAIL PROTECTED]>
Subject: Re: Newbiehelp
Date: Mon, 30 Aug 1999 23:15:15 -0400
I asked the question previously and recieved these responses:
First read the sci.crypt FAQ list (pointer to which is posted about
once a month, but it's easy to locate copies with a Web search),
which not only explains a few things but more importantly lists
several books where you can learn more. With just a high school
background, I'd recommend starting with David Kahn's "The
Codebreakers", preferably the unabridged hardcover edition; it was
on the best-seller list and should be in many public libraries.
***********************************************************
You can get just about everything you want on the internet. I like DJGPP
GNU C it the best C compiler out there. Don't trust the experts. Build up your
own tools. Everything you need at least for now is free on the net. IF you
want a windows based porgramming language teach your self Liberty Basic
it is easy to write games and such in it. Get your own web page to change
ideas with people. Just remember people think differetnt so you will still get
mostly Bull Shit form people so sift though the letters ande hate mail
carefully. IF you write as much as I do be prepared to get death threats.
I get a few every year. ALso besides the Codebreakers which is a good book.
Try the Puzzle Palace. But most books on crypto have a underlying spin to
them. I think it is becasue of the great control the NSA and such groups keep
on the system with there idle billions of dollars. Be warey of error recovery
methods and short key ciphers. ""The sole purpose of encrpytion is to make it
hard to break"". Any thing that you can see is a that is a weakness is a hudge
weakness even if the crypto gods seem programmed to ignore it.
Do things you can varify yourself. For example ALL the 3 letter chaining
methods are weak since they are designed for error recovery yet most don't
see this. You can test this out.
Encrypt your file with a method ( if it changes the length the program can
hide details for you so it takes more work and should not be trusted until
you understand the source code on your own) of the block cipher of
your choice using the 3 letter chaining of your choice. Then reverse the file
( I have code at my site to do this) encrypt a gain with different key and
even different block size program if you wish and your choice of chaining
then take the finiall out put and with a hex editor change one bit or byte or
3 or 4 bytes near the middle of the file. Then decrypt using the reverse
of the encryption methods you used. Surprise the only errors in the
decryption are in the same areas you changed. People have a very
hard time seeing this or even beliveing this until they do it them selves.
This is for 2 reasons. The socalled experts possiblly influenced either
direcrtly or indirectly by the NSA billions. don't want it known. Or they
spout that it is well known and that it is need for error recovery. IF you
belive them then you belive the chinese money the DNC got was
an honest gift. And that we never helped light the Waco fires. And
that the FOX reports about those in Federal Service that have been
recieve bonues did so for other work and not the crooked things
that some are accused. Like the one who released damaging
stuff on Tripp. Why is it fox seem to be the only News service
that wants to tell something about the truth.
David A. Scott
************************************************************
Well, my web site is free (and designed not to demand a lot of
knowledge about mathematics to understand) - and it recommends three
of the best books, The Codebreakers, by David Kahn, Elementary
Cryptanalysis, by Helen Fouche Gaines, and Applied Cryptography by
Bruce Schneier. You won't always find all three of these at every
library, but there are other good introductory books as well.
John Savard ( teneerf<- )
http://www.ecn.ab.ca/~jsavard/crypto.htm
************************************************************
It's a good site, (I am painstakingly downloading John's treatise on
cryptography) and the books recommended cannot be bettered as
introductions to a fascinating subject.
--
Regards, Jim. | We have decided not to go to France
amadeus%netcomuk.co.uk | this summer as it is too full of
dynastic%cwcom.net | unattractive, shirtless Englishmen
| talking into mobile 'phones.
PGP Key: pgpkeys.mit.edu:11371 | - Auberon Waugh.
B3avis wrote:
> Hey there,
> I am pretty new at encryption, but I am VERY interested. Does anyone of you
> know where to find some good sites that handle about it ? Please reply soon,
>
> B3avis
> http://come.to/bchicken
------------------------------
From: "rosi" <[EMAIL PROTECTED]>
Subject: Re: public key encryption - unlicensed algorithm
Date: Mon, 30 Aug 1999 22:45:14 -0400
Have questions, but first 'a couple' of words.
Do not remember the details, but unless you would like to conform
to the 'standard', you do not have to be compliant. You may just use
the general frame. However, it seems that you may want to have
something interoperable. Also, being compliant may mean you do
not have bugs of your creation.
No idea about licensing.
My questions (if David or anybody can give a bit of details): Does
SET specify the performing of identification both ways? Or is it
only the client to be identified? In implementation terms, if 'both
ways', is there some requirement on the client's computing power?
Does SET specify that a 'two-layer' scheme of the following (I could
be mixing things up here, sorry):
E.g. RSA-1024 for general operations and RSA-4096 for
refreshing the RSA-1024.
Thanks for any details provided.
--- (My Signature)
shivers wrote in message
<[EMAIL PROTECTED]>...
>
>David A Molnar wrote in message <7qethp$fod$[EMAIL PROTECTED]>...
>>shivers <[EMAIL PROTECTED]> wrote:
>>> The main purpose is for the development of a _very_ secure online credit
>>> card submission system - where the details stay encryption all the way
>from
>>> the user's desktop to the serving company's payment processing desk.
>>
>>Have you looked at the SET protocol ?
>>
>
>no, I've never heard of it - is it any good? I.e. strong and unlicensed?
>
>Shane Wright
>ProActive Computing
>
>
>
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: public key encryption - unlicensed algorithm
Date: 31 Aug 1999 02:01:31 GMT
shivers <[EMAIL PROTECTED]> wrote:
> no, I've never heard of it - is it any good?
It's the standard which Visa developed and has been pushing here in the
U.S. The design was influenced by a paper on "iKP" , available at
http://www.cs.ucsd.edu/users/mihir/papers/ikp.html
>I.e. strong and unlicensed?
strong : the people who worked on iKP are experienced cryptographers. I
haven't looked at SET enough to say for myself, but it seems to have the
right idea.
Definitions, programmers guides, etc. are at
http://www.setco.org/download.html/
There's a lot of info on the page about a "compliance testing program"
which costs $$ before you are allowed to claim compliance with the
standard. They also have links to two U.S. patents. If you're developing
something which doesn't require an official stamp of compliance, it's not
clear to me whether or not you will need to pay.
In any case, it may be worth looking at the patents to ensure your
eventual solution doesn't infringe somehow.
Thanks,
-David Molnar
------------------------------
** 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
******************************
