Cryptography-Digest Digest #563, Volume #13 Fri, 26 Jan 01 20:13:01 EST
Contents:
Re: Dynamic Transposition Revisited (long) (John Savard)
Re: What do you do with broken crypto hardware? (Paul Rubin)
Re: Cryptographic Camouflage (Thomas Wu)
Re: What do you do with broken crypto hardware? (David Schwartz)
Re: Why Microsoft's Product Activation Stinks (Splaat23)
RSA Source code ("Adam Smith")
Re: Mr Szopa's encryption (was Why Microsoft's Product Activation Stinks) (Alan
Mackenzie)
Re: Why Microsoft's Product Activation Stinks (Splaat23)
Re: Why Microsoft's Product Activation Stinks (Splaat23)
Re: RSA Source code (Paul Rubin)
Re: RSA Source code ("Joseph Ashwood")
Re: Dynamic Transposition Revisited (long) (Terry Ritter)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Dynamic Transposition Revisited (long)
Date: Fri, 26 Jan 2001 23:30:36 GMT
On Fri, 26 Jan 2001 21:48:40 GMT, [EMAIL PROTECTED] (Terry Ritter) wrote,
in part:
>The DES keyspace is 56 bits, a value 2 bits long.
>Let's see: A value 10**21 bits long compared to a value 2 bits long.
>Yeah, I'd say "some" were impossible to reach.
Actually, 56 is a 6-bit-long binary number. And DES doesn't have 56
different keys, it has 2^56 different keys, as noted below.
>The DES keyspace is such a tiny fragment of the potential keyspace
>that there is no assurance at all that it retains the smooth
>theoretical properties of distribution for which we might hope.
quoting me:
>>Well, by shuffling, I can't reach a total overall pairing of bit
>>balanced inputs to bit balanced outputs such that
>>
>>0000000011111111 -> 1111111100000000
>>
>>and
>>
>>0000001010111111 -> 0000000011111111
>
>Why not? What does that mean? Are you criticizing the balancing
>algorithm? Fine, use another.
This has nothing to do with the balancing algorithm.
This is about Dynamic Transposition itself.
All possible N! transpositions of an N-bit block may be effected.
However, 16! is also a tiny fraction of 12870!, just as 2^56 (not 56)
is a tiny fraction of (2^64)!.
If our PRTG - pseudorandom transposition generator - generates the
transposition
9 12 14 16 15 11 10 13 3 5 1 2 7 6 4 8
then if the plaintext was
0000000011111111
the ciphertext will be
111111110000000
and if the plaintext was
0000001010111111
the ciphertext would be instead
1111110100001000
note that just as we have switched two bits in our plaintext, we have
switched two bits in our ciphertext.
A substitution cannot be reached by means of any transposition that
will at the same time take
0000000011111111
to
1111111100000000
and take
0000001010111111
to
0000000011111111
since we are inverting a different number of bits in the plaintext and
the ciphertext.
Thus, as with DES, some total overall mappings, considering the whole
ensemble of (plaintext, ciphertext) pairs generated at a single point
in the process, are unreachable.
This is not so much a criticism of Dynamic Transposition itself as of
your claim that it is vastly superior to DES with
stream-cipher-generated subkeys.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: Paul Rubin <[EMAIL PROTECTED]>
Subject: Re: What do you do with broken crypto hardware?
Date: 26 Jan 2001 15:48:42 -0800
Nicol So <[EMAIL PROTECTED]> writes:
> > Maybe I'm overly paranoid but the encrypted external keys are in disk
> > files on the application host, and I'm going by the assumption that
> > the online application host is completely insecure.
>
> I'm not familiar with your application, but it sounds dangerous if the
> application host is completely insecure.
To clarify: we do all the usual things to make the host secure, but
despite this I assume there's a chance it can be compromised, and
that's what the module is supposed to protect against.
------------------------------
From: Thomas Wu <[EMAIL PROTECTED]>
Subject: Re: Cryptographic Camouflage
Date: 26 Jan 2001 15:50:23 -0800
Mok-Kong Shen <[EMAIL PROTECTED]> writes:
> Thomas Wu wrote:
> >
> > Mok-Kong Shen <[EMAIL PROTECTED]> writes:
> >
> > > Darren New wrote:
> > > >
> > > > I.e., it looks like it's protecting against offline searches of passwords
> > > > you can only truely verify online.
> > > >
> > > > Of course, that's just my interpretation. Read the actual patent for what
> > > > they're actually covering.
> > >
> > > Thank you very much. For, trusting that you are right, I don't
> > > think I would spend time to study the detailed document.
> > >
> > > So it seems that it is virtually the 'employment' of a checksum
> > > that gets patented. When I was in school, solving some systems
> >
> > Huh? It's just the opposite. Having a checksum (MAC, etc.) that
> > validates a password guess is exactly what camouflage avoids.
> > By removing this checksum, and doing some other cleverness, you
> > get a blob of data that leaks no information about the PIN that
> > unlocks it. Yet when the right guy comes along with the right
> > PIN, the correct private key (RSA, DSA, etc.) is constructed and
> > used. Doing this right involves designing the key formats,
> > algorithms, and protocols carefully so that this property is
> > preserved, and that's where the non-triviality comes in.
> >
> > I happen to work with this technology on a daily basis, so I get
> > to see those non-trivialities quite often.
>
> I based on the information from Darren New, which I hope
> to have interpreted correctly.
Darren New's post seemed to be accurate. You then posted a message
that was a non-sequitur; you seem to have misread his post and gotten
exactly the opposite of what he meant. I am attempting to correct
that misinterpretation. Please read his post (and the patent) more
carefully.
> M. K. Shen
Tom
--
Tom Wu * finger -l [EMAIL PROTECTED] for PGP key *
E-mail: [EMAIL PROTECTED] "Those who would give up their freedoms in
Phone: (650) 723-1565 exchange for security deserve neither."
http://www-cs-students.stanford.edu/~tjw/ http://srp.stanford.edu/srp/
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: What do you do with broken crypto hardware?
Date: Fri, 26 Jan 2001 15:54:15 -0800
John Savard wrote:
> The key stored inside the module decrypts the encrypted keys on your
> hard drive.
Correct.
> But when the module breaks, you don't send the manufacturer a copy of
> your hard drive; _although_ the keys on your hard drive are encrypted,
> they are still treated as sensitive, and are not transmitted anywhere
> or left open to public access.
If you could trust your hard drive to store your keys, you wouldn't
need the module for anything.
> So you have to use the 'module' you buy as a component in a larger
> 'module' you make yourself, as it were.
Then what do you need the module for? Why not just use the hard drive
in the larger module you make yourself as the module?
I don't think you can have it both ways. You can consider those keys to
be sensitive, and assume that if someone gets them, security is
compromised -- in which case the module gets you nothing. Or you can
consider those keys to be encrypted and hence it doesn't matter if
anyone gets them -- in which case you can't let anyone else have the
module.
The more you begin to have to trust the host machine, the less the
module actually gets you.
DS
------------------------------
From: Splaat23 <[EMAIL PROTECTED]>
Crossposted-To: or.politics,talk.politics.crypto,misc.survivalism
Subject: Re: Why Microsoft's Product Activation Stinks
Date: Fri, 26 Jan 2001 23:57:17 GMT
An interesting question for you, Mr. Szopa, that is very relevant to
this discussion is the following: Do you really believe that anti-
piracy in Microsoft's or your manner can actually be successful?
Because I don't, and if your "invention" doesn't work, then who really
cares if Microsoft stole it from you or not.
- Andrew
In article <[EMAIL PROTECTED]>,
Anthony Stephen Szopa <[EMAIL PROTECTED]> wrote:
Just about nothing.
Sent via Deja.com
http://www.deja.com/
------------------------------
From: "Adam Smith" <[EMAIL PROTECTED]>
Subject: RSA Source code
Date: Sat, 27 Jan 2001 00:13:22 GMT
I'm looking for RSA source code in C/C++/MFC...anyone know where I can find
it? I need at least 512 bits...DH/DSS would work also...
any tips?
Thanks!
Adam Smith
------------------------------
From: Alan Mackenzie<[EMAIL PROTECTED]>
Crossposted-To: or.politics,talk.politics.crypto,misc.survivalism
Subject: Re: Mr Szopa's encryption (was Why Microsoft's Product Activation Stinks)
Date: Sat, 27 Jan 2001 00:09:28 +0000
Anthony Stephen Szopa <[EMAIL PROTECTED]> wrote on Thu, 25 Jan 2001
23:49:47 -0800:
> Taneli Huuskonen wrote:
[ .... ]
>> I claimed that the raw digit stream from your pseudorandom digit
>> generator is predictable under certain conditions. I was prepared to
>> back up my claim by predicting some digits, given a long enough sample
>> of the output of the pseudorandom digit generator. I never got the
>> challenge sample from you, though, so I presume you aren't contesting my
>> claim per se, only its relevance to the strength of your encryption. I
>> concede that you may be right, for all I know, but still, IMAO, you
>> should address this issue on your Web site and explain your reasons for
>> believing that the predictability of the pseudorandom digit stream
>> doesn't weaken the encryption.
>> Taneli Huuskonen
[ .... ]
> I already have answered your proposal over a few posts way back when.
> There are certain agreed upon criteria upon which an encryption
> scheme is to be attacked. Yours is completely different from this
> and obviously unacceptable. This criteria is well known and is not
> arbitrary. It is a logical set of criteria based upon real world
> circumstance and situation.
> Answer us this: where are you proposing getting the raw random digit
> output from the random number generator to break someone's key?
Well, for example, it may be possible to predict a standard prologue in
an encrypted message, and derive some length of the encryption stream
from it; or at least, considerably narrow the search space for the stream
at that point. This in its turn might be sufficient to predict the
encryption stream for the substantial part of the message.
> The answer of why your suggestion doesn't weaken the encryption is
> obvious on its face. You'll never get the raw random digit output
> from the random digit generator. If you could, then you could
> probably get the key, and the final OTPs as well. Why even bother
> to attempt to break the encryption under these circumstances.
Are you saying that if one has access to the raw random digits, one can
work backwards and derive the key from them?
> But let's just say somehow you did get the raw random digit output
> from the random number generator and let's say you even got the
> entire three MixFiles.
> About 28% of the raw random digit triplets are going to be thrown out at
> random. Then the remaining 72% or so of the triplets are going to
> be divided to get a stream of random numbers from 0 - 255. Then these
> several random number streams will be combined in numerous different
> ways and finally once again when the final OTPs are generated.
It is to be able to verify such assertions that people want access to the
source code.
> How are you going to get from the raw random digit output from the
> random digit generator to the triplets that are kept to the random
> number streams containing the numbers from 0 - 255 and then how are
> you going to get to the final OTPs?
Such a question can only be answered, if there is an answer, once the
algorithm is known in complete detail.
> If you are planning to break the encryption you cannot stop with the
> raw random digit output or working backwards to the MixFiles. You
> must continue forward to the final process and predetermine the final
> OTP files.
Again, it would be useful for this assertion to be checked (i.e.
attacked) by a third party.
> You haven't even come close.
Is the security of this system dependant on the secrecy of the algorithm?
> Your whole original premise is not thorough or logical. Ultimately,
> it has no bearing on the breaking of OAP-L3.
It would seem to me to have a substantial relevance to breaking the
algorithm, or alternatively, to creating confidence in its security.
--
Alan Mackenzie (Munich, Germany)
Email: [EMAIL PROTECTED]; to decode, wherever there is a repeated letter
(like "aa"), remove one of them (leaving, say, "a").
------------------------------
From: Splaat23 <[EMAIL PROTECTED]>
Crossposted-To: or.politics,talk.politics.crypto,misc.survivalism
Subject: Re: Why Microsoft's Product Activation Stinks
Date: Sat, 27 Jan 2001 00:05:07 GMT
Do you even know what a spammer is? Because this individual is not.
You don't seem to understand that the source code _is_ available, just
in slightly obfuscated form. If your program was protecting anything
valuable, people might spend the time to reverse-engineer it. Then
you'd get the security analysis that would vindicate/condemn your
software. But since no one here wants to spend a lot of time to satisfy
some obnoxious usenet poster's cipher, if you _really_ are so sure of
your algorithm, save us some time and give us the source.
Unless, of course, you think your source code is somehow unobtainable.
In which case you're just an idiot.
You are a very confrontational person - when you are the one attacking.
But whenever you feel attacked, you simply don't respond. Would you
mind actually responding rather this time?
- Andrew
In article <[EMAIL PROTECTED]>,
Anthony Stephen Szopa <[EMAIL PROTECTED]> wrote:
> Richard Heathfield wrote:
> >
> > Anthony Stephen Szopa wrote:
> > >
> > > Pointless program where to stop software piracy could increase
> > > revenues by tens of billions of dollars each year? Pointless?
> >
> > Pretty much, yes. It's like trying to protect Pythagoras' Theorem.
> > Counter-productive.
> >
> > > I will not defend copy protection here and now. You slide on this
> > > point.
> >
> > (I don't know whether "slide on this point" is American idiomatic
usage,
> > but I don't /quite/ understand it. But I'm guessing it means you
don't
> > want to talk about copy protection. Fair enough.)
> >
> > >
> > > Some people like the XOR program and have downloaded it. It works
> > > just fine as someone in this news group pointed out.
> >
> > It would be astonishing if it /didn't/ work just fine. It's not
exactly
> > a tricky program to write, is it?
> >
> > > And here you
> > > go again, trying to assail my software's aesthetics.
> >
> > I don't have to assail it. People only need look at it to make
their own
> > minds up.
> >
> > > Can't prove anything negative about the theory of OAP-L3?
> >
> > Until you release the source code, why should anyone bother trying?
> >
> > And, until it can be *used* conveniently (my understanding is that,
at
> > present, the user is obliged to shuffle cards for an hour or
three), why
> > should anyone bother trying?
> >
> >
> > > Say, you don't want anybody stealing your money: give it away,
it's
> > > that simple, too.
> >
> > That's the first rational debating point you've made.
> >
> > My answer? Simple, really. High quality software is being written
for
> > free, every day. It's very competitive on price. Example: I can get
a
> > very powerful operating system that works for 100% less than it
costs me
> > to buy a slightly less powerful and broken operating system. Think
about
> > it. It'll take a while for people to catch on to the idea that they
> > don't have to pay for their software, but they'll cotton on
eventually.
> >
> > This works in encryption software too (to get us at least marginally
> > back on-topic). Since people are writing better cryptographic
products
> > than yours for free, why should anyone pay for yours?
> >
> > By the way, the source code for Twofish is freely available, and
Twofish
> > has been heavily analysed.
> >
> > >
> > > You still haven't figured out why I wrote the XOR program and
posted
> > > it on my web site for all to download. I guess if you don't get
it:
> > > you just don't get it.
> >
> > No, I don't get it. But I can't /wait/ for you to explain. What will
> > your next masterpiece be? A program to add two numbers together?
Without
> > source code, and weighing in at 300 KB?
> >
> > >
> > > I mentioned to a guy once that US laser weapons are only about 10%
> > > efficient. He said who cares, they get the job done.
> >
> > If you have the choice between 10% efficiency and 90% efficiency,
which
> > do you choose? If I have the choice between OAP-L3 and Twofish, I
choose
> > Twofish. Why? Because it's free, it is known to work (or, at least,
has
> > been extensively cryptanalysed with no known breaks surfacing as
yet),
> > it's fast, and the source code is available.
> >
> > > What are MSs objectives? It matters.
> > >
> > > MS is losing a bundle on its software being pirated. You are just
> > > spamming when you ask who would want MSs software. The answer is
> > > just about everybody, especially if its free.
> >
> > The price is still too high. If you can persuade MS to /pay/ me to
have
> > their software, I /might/ consider it.
> >
> > --
> > Richard Heathfield
> > "Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
> > C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
> > K&R Answers: http://users.powernet.co.uk/eton/kandr2/index.html
>
> You are a spammer.
>
> Anyone reading your posts / replies can easily tell.
>
> In the university when you take a test, you are not given data to
> solve the problem. You solve the problem by using the techniques
> on variables. If you cannot solve the problem on variables you
> cannot solve the problem when these variables are assigned values.
>
> The theory upon which OAP-L3 is based is completely explained in
> the help files readily available from the web site:
> http://www.ciphile.com
>
> If you cannot assail the encryption based upon any hoped for
> weakness in the theory then you cannot assail the encryption theory
> knowing the source code.
>
> What you are hoping to do is not disprove the theory but are
> slumming in hopes of finding a bug in the implementation.
>
> You must first admit that you have given up on any hopes to assail
> the theory upon which OAP-L3 is based before we even get on with
> discussing the source code.
>
> So, is this the end of your spamming?
>
> We all hope so.
>
Sent via Deja.com
http://www.deja.com/
------------------------------
From: Splaat23 <[EMAIL PROTECTED]>
Crossposted-To: or.politics,talk.politics.crypto,misc.survivalism
Subject: Re: Why Microsoft's Product Activation Stinks
Date: Sat, 27 Jan 2001 00:10:14 GMT
Someone needs to school you in the facts of piracy: people have been
using "keys" for years. They are called "cd-keys", "serial numbers",
etc. What they have never done is worked when they are not really
protecting anything.
In this case, what don't you get if your special, configuration-based
key changes? You go down the wrong end of an "if" statement. That's it.
Of course, it can be made more complex than that, but whatever MSFT can
do can be reversed as well.
I guess, in a way, this whole flame-war has been a result of you
refusing to believe that your "invention", stolen my MSFT, cannot
really work.
- Andrew
In article <[EMAIL PROTECTED]>,
Anthony Stephen Szopa <[EMAIL PROTECTED]> wrote:
> Richard Heathfield wrote:
> >
> > Lord Running Clam wrote:
> > >
> > > -----BEGIN PGP SIGNED MESSAGE-----
> > >
> > > On Fri, 26 Jan 2001, Richard Heathfield <[EMAIL PROTECTED]>
wrote:
> > > >Anthony Stephen Szopa wrote:
> > > >>
> > > >> Pointless program where to stop software piracy could increase
> > > >> revenues by tens of billions of dollars each year? Pointless?
> > > >
> > > >Pretty much, yes. It's like trying to protect Pythagoras'
Theorem.
> > > >Counter-productive.
> > >
> > > Excuse me, but is this little piece from alt.security.pgp
relevant to your
> > > flamewar?
> > >
> > > http://www.deja.com/[ST_rn=ps]/getdoc.xp?AN=720256016&fmt=text
> >
> > Yes, indeed. I think it sums up one of the points nicely. If
Microsoft
> > want copy protection to actually work, they need to do it in
hardware.
> > That way, the cost of making a copy is likely to exceed the cost of
> > buying one in the shops. Of course, I'm not convinced that anyone's
> > going to buy any Microsoft hardware more complicated than a mouse,
but
> > that's for each user (or IT dept) to decide, of course.
> >
> > As for the flamewar, well, I'm not terribly interested in
prolonging it.
> > But 'twas mildly diverting while it lasted. :-)
> >
> > --
> > Richard Heathfield
> > "Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
> > C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
> > K&R answers, C books, etc: http://users.powernet.co.uk/eton
>
> You have proved you do not understand what MS is doing.
>
> Essentially MS is relying on hardware and software.
>
> They are ferreting out any and all data from your computer either
> from software, firmware, or hardware that will uniquely identify
> it.
>
> You don't have to buy or be sold any new hardware or software or
> firmware.
>
> But if you do and change significantly your computers configuration,
> which might also change the unique identification of your computer
> then you would need a new password according to MS's anti-piracy
> "innovation" and mine as well since MS's anti-piracy "innovation" is
> at least partly based upon my anti-piracy invention.
>
> Take that, you!
>
Sent via Deja.com
http://www.deja.com/
------------------------------
From: Paul Rubin <[EMAIL PROTECTED]>
Subject: Re: RSA Source code
Date: 26 Jan 2001 16:22:59 -0800
"Adam Smith" <[EMAIL PROTECTED]> writes:
> I'm looking for RSA source code in C/C++/MFC...anyone know where I can find
> it? I need at least 512 bits...DH/DSS would work also...
>
> any tips?
http://www.openssl.org OpenSSL package
http://indigo.ie/~mscott MIRACL package
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: RSA Source code
Date: Fri, 26 Jan 2001 16:22:08 -0800
"Adam Smith" <[EMAIL PROTECTED]> wrote in message
news:Cooc6.2631$[EMAIL PROTECTED]...
> I'm looking for RSA source code in C/C++/MFC...anyone know where I can
find
> it? I need at least 512 bits...DH/DSS would work also...
Well you could go to www.openssl.org, and download it. Or you could get a
bignum package and write your own.
RSA is:
p = prime
q = prime
e = prime
(three different primes)
d = e^-1 mod (p-1)(q-1)
Encryption:
X = M^e mod pq
decryption
M = X^d mod pq
signing and verification
depends vastly on what signature type you do
DH is even easier.
Joe
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Dynamic Transposition Revisited (long)
Date: Sat, 27 Jan 2001 00:37:03 GMT
On Fri, 26 Jan 2001 21:48:40 GMT, in <[EMAIL PROTECTED]>,
in sci.crypt [EMAIL PROTECTED] (Terry Ritter) wrote:
Please, somebody save me from myself!
>>[...]
>>But Terry Ritter appears to be criticizing DES because some of the
>>(2^64)! possible overall substitutions are impossible to reach.
>
>Some? SOME???!!
>
>(From my factorials page:
>
> http://www.io.com/~ritter/JAVASCRP/PERMCOMB.HTM
>
>).
>
>(The number of different values in 64 bits is 2**64.)
>2**64 ~= 18446744073709552000 = A
>A! ~= some value 1.15397859e+21 bits long.
>The DES keyspace is 56 bits, a value 2 bits long.
No, the DES keyspace is 56 bits, ironically enough.
>Let's see: A value 10**21 bits long compared to a value 2 bits long.
That would be: "A value 10**21 bits long compared to a value 56 bits
long."
But the conclusions remain:
>Yeah, I'd say "some" were impossible to reach.
>
>The DES keyspace is such a tiny fragment of the potential keyspace
>that there is no assurance at all that it retains the smooth
>theoretical properties of distribution for which we might hope.
>[...]
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
** 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 by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
