Cryptography-Digest Digest #585, Volume #13 Mon, 29 Jan 01 09:13:00 EST
Contents:
Re: Mr Szopa's encryption (was Why Microsoft's Product Activation Stinks) (Lord
Running Clam)
Looking for Universal electronic cash by T. Okamoto and K. Ohta ("P.C. Teo")
Re: Why Microsoft's Product Activation Stinks (Richard Heathfield)
Re: brute force and Moore's law (was Re: 32768-bit cryptography) (Paul Crowley)
Re: Cryptographic Windows APIs or OCX? (Daniel James)
Re: Windows encryption: API and file system (Daniel James)
Re: Why Microsoft's Product Activation Stinks (Lord Running Clam)
On combining permutations and substitutions in encryption (Mok-Kong Shen)
Re: Security of FirstClass Software (Ichinin)
Re: RSA Source code (Ichinin)
Re: Paranoia (Ichinin)
RSA: Finding the private exp instead of factoring ("The Death")
Re: William's P+1 (Mika R S Kojo)
Re: Security of Centrinity's FirstClass Product (those who know me have no need of
my name)
----------------------------------------------------------------------------
Date: Mon, 29 Jan 2001 03:51:45 -0600
From: Lord Running Clam <Use-Author-Address-Header@[127.1]>
Subject: Re: Mr Szopa's encryption (was Why Microsoft's Product Activation Stinks)
Crossposted-To: talk.politics.crypto
=====BEGIN PGP SIGNED MESSAGE=====
On Sun, 28 Jan 2001, Anthony Stephen Szopa <[EMAIL PROTECTED]> wrote:
>The rules state that the cracker has enough plain text / cipher text
>such that to have any more won't make any difference.
>
>You have not or cannot support or justify your 2. assumption.
Who cares what you *think* the rules are?
Hack! Hack! Hack!
Here, have another 0.02cents and some more edjuyacashun....
Why should I bother to go to locksmith school; when you leave a key under
the doormat?
F---Ups set. ;-) 'cos I can see I'll end up poor before you ever learn.
LRC.
- --
The bigger the humbug, the better people will like it.
~ Phineas Taylor Barnum.
=====BEGIN PGP SIGNATURE=====
Version: N/A
iQEVAwUBOnSkcoer+ijnZohVAQFjZQf+IWjpLuDl1r/yrc/trif/Kd5380ryJLTk
u0FFyLnag2u9yj2B5jfbgemJktEOzEaCrWeWE0rYnoRObg3nIYjS3deUlN+Xm2Hc
pwI/nkUrZ+WAzzOIqRPXO8wJs6OQfeA+3C/2O9M4yKm490eAaV5uuGzJ1ZrSuSzC
RseFuvhrMIWshEUPu5LthMT+KLRpJ4gYCJabDucXScTHyeCivWlOkVhYz3qKLmG7
yrrkBI5uLNU4hVvqAtXP7gYmkwkrvAc9jPImb/ET80UmkVa/pLmEFcbbBNL3sGo3
hUcX5SA14nJBdUSQGB/a+yBM6inAMZ7wJ+qiaSCtNMSUpC+wJG5mBg==
=AI4o
=====END PGP SIGNATURE=====
------------------------------
From: "P.C. Teo" <[EMAIL PROTECTED]>
Subject: Looking for Universal electronic cash by T. Okamoto and K. Ohta
Date: Mon, 29 Jan 2001 18:19:28 +0800
Reply-To: "P.C. Teo" <[EMAIL PROTECTED]>
Can anyone tell me how to get one electronic copy of the paper mentioned
above?
I tried all my best but still couldn't find one.
Thanks
------------------------------
Date: Mon, 29 Jan 2001 11:22:49 +0000
From: Richard Heathfield <[EMAIL PROTECTED]>
Crossposted-To: or.politics,talk.politics.crypto,misc.survivalism
Subject: Re: Why Microsoft's Product Activation Stinks
Anthony Stephen Szopa wrote:
>
<snip>
>
> 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.
Interesting. Are you claiming that MS have done a Ken on gcc [1]? If so,
some evidence would be useful. It might even be topical. I suspect,
however, that you are not claiming this, but that you simply cannot
imagine the possibility that some people might use software not written
by Microsoft.
[1: An explanation might be in order. You seem to be claiming that
Microsoft have a patch in the gcc binary for Linux, similar to a patch
on early C compilers described by Ken to the ACM a few years ago. This
is the only way they could hope to hide "ferreting code" in Linux
without its showing up in the sources. Getting universal coverage would
be practically hopeless, I think, even if they could guarantee that
nobody in the Linux community has gone into gcc with a disassembler on
the off-chance of finding something like this.]
> You don't have to buy or be sold any new hardware or software or
> firmware.
You're right there. I don't buy new software. I prefer to use working
software.
> 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.
No, sir, I would need no such password.
> Take that, you!
Huh? Take what?
--
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
------------------------------
Subject: Re: brute force and Moore's law (was Re: 32768-bit cryptography)
From: Paul Crowley <[EMAIL PROTECTED]>
Date: Mon, 29 Jan 2001 10:20:44 GMT
Paul Rubin <[EMAIL PROTECTED]> writes:
> Eric Smith <[EMAIL PROTECTED]> writes:
> > > There are good reasons for this: a 168-bit 3DES key isn't
> > > that much more secure than a 112-bit 3DES key,
> >
> > Doesn't the 2^112 operation attack on 168-bit 3DES require
> > 2^112 words of memory?
>
> No, just 2^56 words. The same MITM attack as usually mentioned
> against 2DES, more or less.
And under some circumstances, Wiener and van Oorschot's parallel
collision search techniques can be used to reduce the memory demands
to entirely practical levels.
--
__
\/ o\ [EMAIL PROTECTED]
/\__/ http://www.cluefactory.org.uk/paul/
------------------------------
From: Daniel James <[EMAIL PROTECTED]>
Subject: Re: Cryptographic Windows APIs or OCX?
Date: Mon, 29 Jan 2001 10:31:35 GMT
Reply-To: [EMAIL PROTECTED]
In article <94k7se$tun$[EMAIL PROTECTED]>, Armando P. wrote:
> I am a software developer and I need to implement SSL (SSLv3/TLS
> if that helps) into my applications ...
> ... I'm in dire need for a good (and well documented)
> Cryptographic API (or Ocx) that I can implement into my existing
> software.
If you're considering MS CryptoAPI you must be writing exclusively for
Windows, so why not just use the internet connectivity functions in
WinInet.dll? They'll handle SSL for you (using MS's S-channel SSPI
DLL).
The CryptoAPI functions are all documented in the Windows SDK
documentation - search for CryptoAPI and/or look for functions with
names starting "Crypt".
Cheers,
Daniel.
------------------------------
From: Daniel James <[EMAIL PROTECTED]>
Subject: Re: Windows encryption: API and file system
Date: Mon, 29 Jan 2001 10:31:35 GMT
Reply-To: [EMAIL PROTECTED]
In article <[EMAIL PROTECTED]>,
Wtshaw wrote:
> > Writing a temporary file is done out of a desire to be able
to
> > recover the data if the encryption process is interrupted by
some
> > fatal error.
>
> How commonly do you face that?
Not very, but if you're marketing encryption software you have
to be very careful not to lose any of the user's data! It only
takes one corporate executive deciding to encrypt a directoryful
of files on a notebook with an almost flat battery to corrupt a
file (this doesn't happen so often now that most notebooks
switch to standby rather than powering right down when the
batteries are low, but is still a problem), and that gives the
encryption software a bad reuptation.
I've known people in IT departments evaluating encryption
software pull the plug deliberately during an encrypt to make
sure that nothing is lost. If the software can't survive that
without losing data nobody buys it.
> You did say NT...well, that is surely one of your problems.
NT is not a problem if the alternative is Windows9x! ... and the
original poster did ask about *Windows* encryption.
Cheers,
Daniel.
------------------------------
Date: Mon, 29 Jan 2001 04:47:48 -0600
From: Lord Running Clam <Use-Author-Address-Header@[127.1]>
Subject: Re: Why Microsoft's Product Activation Stinks
Crossposted-To: or.politics,talk.politics.crypto,misc.survivalism
=====BEGIN PGP SIGNED MESSAGE=====
On Mon, 29 Jan 2001, Anthony Stephen Szopa <[EMAIL PROTECTED]> stated
that he did not unnerstand what:
>Bill Unruh wrote:
<snip>
>If Whistler, compiled for 64 bit machines is a great product people
>will want it badly. The same is true for other 64 bit compiled
>major software applications.
>MS and the Industry in general are in a great bargaining position.
>If you don't want a 64 bit operating system then don't buy it and
>run Windows 98 or ME on your Pentium IV computer. And when Pentium
>V comes out at 128 bits keep on using your Windows 98 32 bit OS.
If you chose to get your software from a 2 bit company, you'll have all the
security they want you to have. Or is it still beyond your comprehension
that they don't like 1 bit of competition? I.e. They would prefer you to
have no choice.
>Even the stockholders of these companies want to have this anti-
>piracy feature implemented.
Slimey software speculators:
Those who can be conned into believing that because nobody they know
can break something, then it is unbreakable.
>Obviously most pirates and jealous and fearful people don't because
>it will give that much more control to BG and the Industry.
Pirates? Methinks it should concern everyone that M$ is flogging snake oil.
>But I believe it will happen nevertheless.
And - in this case - you might be right, but for the wrong reasons.
Here, have another 0.02cents for your collection.
LRC.
- --
Wednesday I watched the riot... | - Frank Zappa.
I seen the cops out on the street | From "Trouble Every Day"
Watched 'em throwin' rocks and stuff | on "Freak Out!"
And chokin' in the heat | July 1966.
=====BEGIN PGP SIGNATURE=====
Version: N/A
iQEVAwUBOnSkcoer+ijnZohVAQGwRwf/fVLhxsw7hwDjt/CO3Nk6/QKUslr6hpJ0
mb7WtppIm6UdKA15UQiksiWrMwLD9Pzt+ItzPROA5w9IymwMtXzAcajiw43XUB8O
cb9+lsohNSNz/NMxBmZwEglFDQx3JfjW5DiN8Xxlu44BT46c0At1rZDsxNY+CeIw
STRqFQ12vKTz8a0z8BK4UaKo6lUghwQ+Ptfrzfvsuls+ej/vSXRoBaXe9tlDfyWK
WOD5lAIEMKMdaX3T7Xo14K+/ifo7cy3jotpubKvbHUsBozU5FT5i4BxtcnnwbUsX
AWelNuIWoZxtT46/MUi/Zvv8LIb8T/H8TB2WJb3FsqNW51IikR1kcA==
=q4m3
=====END PGP SIGNATURE=====
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: On combining permutations and substitutions in encryption
Date: Mon, 29 Jan 2001 11:59:31 +0100
Although for historical and/or didactic reasons permutation
(transposititon) and substitution are commonly treated as
more or less independent concepts, it is apparent that the
former is a special case of the latter. For units of n bits,
there are (2^n)! bijective mappings that are substitutions,
of which permutations form a comparatively small subset of
n! mappings. From this general vs. special relationship,
permutations may (very loosely speaking) be considered to
be less versatile/powerful than substitutions.
However, this makes sense only when comparison is done with
the same value of n. For large values of n, specifying a
permutation is in practice relatively simple, either through
giving the values of the indices of the permuted elements
with respect to the original sequence or through giving e.g.
a PRNG and the algorithm of Durstenfeld. On the other hand,
specifying an arbitrary substitution requires a table (S-box),
which could pose already in cases of moderately large values
of n certain difficulties of implementation.
Obviously, the larger the n, the better will in general be
the mapping in respect of strength. From the above
considerations it can therefore be said that an optimal
combination of permutations and substitutions would be
combining permutations of large n values with substitutions
of moderate n values (values that are not too small but
yet small enough to enable reasonable implementation).
Permutation implies also a granularity. One can permute
at the bit/byte/word level or using other units. On common
computers, however, it is fastest to move words, while
moving bits around is comparatively slow. In my humble
opinion, it therefore seems that a reasonable middle-way
is to permute bytes of 8 bits. As to substitution, an 8-bit
unit appears to be approximately of its maximum magnitude.
(A 10-bit unit would also be o.k. but it doesn't work very
well with the byte/word size of the computers, because 10
isn't a factor of 32 or 64. For the same reason, another
choice would be a 4-bit unit.) However, combining
permutation of bytes with substitutions of bytes is
evidently not optimal, for there would be no 'interactions'
between bits of different bytes of the message. One way of
improving the matter is to apply rotation to the words
(each word encompasses 4 or 8 bytes in the common hardware),
thus effecting certain interactions. This rotation can be
either of constant magnitude (e.g. 4 bits) or of variable
magnitude.
Obviously it would be beneficial to use a large number of
different permutations and substitutions in an encryption
run. Using a PRNG, one can generate a sufficiently large
number of tables specifying the permutations (the indices)
and substitutions (the S-boxes) as well as rotations (the
magnitudes). Then for a given block to be encrypted one
can let the PRNG generate numbers to index these tables
to obtain the permutations, substitutions and rotations
needed. This is evidently more economical (in terms of
PRNG output) than generating these dynamically (on the
fly), though it could be, in comparison, inferior in
aspect of strength, because less PRNG output is involved
in the operations. One can, however, as a compromise let
the user choose to refresh, i.e. change, these tables at
certain intervals of the encryption run, if desired.
Since the PRNG output is not 'directly' used, as would have
been the case of using it to xor the plaintext, the values
of its output are never directly exposed to the opponent
in the combination depicted above, even if he acquires
both plaintext and ciphertext. This 'indirectness' of
employment of the PRNG output largely shields its
predictability from being exploited. On the other hand, we
evidently cannot in practice have any guarantee of 'absolute'
infeasibility of analysis resulting alone from the said
'indirectness', particularly if fast-runing PRNGs are used,
which are normally only statistically good but not provably
crypto-secure. (Suitably combining a number of PRNGs could
render the prediction more difficult. See my web page for a
scheme I suggested.) That is, the predictability of the
PRNG used cannot be caused (by whatever devices) in practice
to magically disappear 'absolutely and entirely' in our
results of encryption, though very much reduced. (This is
like one cannot magically create a mechanism that runs by
itself forever but only one that utilizes the energy
supplied efficiently). In order to obtain sufficient
strength, one can (should) evidently use, as is commonly
the case with most known block ciphers, more than one
round of our combination and employ additional operations,
e.g. the autokey technique and modular addition of bit
sequences from the PRNG.
We note that, while the size of the unit of substitutions
has little good choices, the value of n for permutations
does not have practical restrictions. Thus we can use any
large block size that is convenient for implementation and
even choose it to be the entire message size (whole file
processing).
An implementation largely guided by the above considerations
may be found in my humble design WEAK3-E, done years ago.
(It employs, though, 4-bit units, has a block size of 640
bits and variable number of rounds. See my web page.)
M. K. Shen
===========================
http://home.t-online.de/home/mok-kong.shen
------------------------------
From: Ichinin <[EMAIL PROTECTED]>
Subject: Re: Security of FirstClass Software
Date: Mon, 29 Jan 2001 11:12:29 GMT
In article <953agr$ajj$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> FC used to have only 40bit keys due
> to the US export restrictions etc. and these days
> 512 is no longer so good.
40 bits of SYMMETRICAL crypto key is NOT equivalent to a 512 bit
ASYMMETRICAL key.
A 40 Bit codebreaking machine can be built by joe average that have
basic skills in cryptografy and some Socket programming skills (Yes,
i've done it!) whereas trying to factor a 512 bit key requires more
computing power and knowledge than that.
Regarding Softarcs First Class:
http://www.ntbugtraq.com/default.asp?
pid=36&sid=1&A2=ind9909&L=NTBUGTRAQ&P=R49
(The above URL should be on one line)
= it totally rely on the security of the rest of the system and it's
services to be imprenetable. (Ciphering or hashing a password is SO
easy!)
Regards,
Ichinin
Sent via Deja.com
http://www.deja.com/
------------------------------
From: Ichinin <[EMAIL PROTECTED]>
Subject: Re: RSA Source code
Date: Mon, 29 Jan 2001 11:15:39 GMT
http://www.vbcode.com/
(Look around)
Regards,
Ichinin
Sent via Deja.com
http://www.deja.com/
------------------------------
From: Ichinin <[EMAIL PROTECTED]>
Subject: Re: Paranoia
Date: Mon, 29 Jan 2001 12:05:03 GMT
In article <[EMAIL PROTECTED]>,
Simon Jenkins <[EMAIL PROTECTED]> wrote:
> If GCHQ aren't interested any more, it means they
> can break it.
No, it doesn't say that, it means that they ara not intrested.
However, _THAT_ can mean:
A) They can break it.
(Unlikely, but don't bet your house on it)
B) They are also paranoid; they cannot trust that
ANYONE ELSE can't break it now when it's out in
the open.
(Sounds reasonable right?)
C) They have their own stuff.
(Sounds most likely.)
> would it be
> economically viable to keep the method secret rather than release it
> into the public domain?
Hmmm, you can read most of the worlds standard PKI encrypted email, Key
agreement (etc) technologies; what would THAT be worth? That's
priceless dude.
Regards,
Ichinin
Sent via Deja.com
http://www.deja.com/
------------------------------
From: "The Death" <[EMAIL PROTECTED]>
Subject: RSA: Finding the private exp instead of factoring
Date: Sun, 28 Jan 2001 17:28:38 +0200
Isn't it easyer sometimes to encrypt a message, and try finding the private
exponent.
The procedure is:
1) Encrypt a message
2) Decrypt by private exponent X
3) Is the decrypted message the same as the original?
* Yes - You found the Private Exponent!
* No - Increase X by 1 and go back to (2)
In practiacl needs of decrypting messages of others, isn't this better?
------------------------------
From: Mika R S Kojo <[EMAIL PROTECTED]>
Subject: Re: William's P+1
Date: 29 Jan 2001 15:20:17 +0200
"Michael Scott" <[EMAIL PROTECTED]> writes:
> "Mika R S Kojo" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> >
> > "The Death" <[EMAIL PROTECTED]> writes:
> > >
> > > Seems there s no reason for me to use it then.
> > > Is it in any way better than Pollard's P-1 ?
> >
> > In the trivial sense yes. It finds a factor p of N if p+1 has small
> > divisors, but Pollard's p-1 finds such that p-1 has small divisors :)
> > ....
>
> In fact so-called (p+1) is in fact a (p+ or -1) method, so in a sense it
> supplants (p-1). But its a little slower.
Do you have a proof that no p+1 method is never deterministically a
p+1 method? That might be interesting. I can see that this is a common
occurrence. With the multiplicative group of a finite field of p^2
elements you get p+1 and p-1 methods. With the elliptic curve y^2 =
x^3 - x, and some other elliptic curves, you have similar phenomena.
My original assumption was that there would exists such a group that
gives deterministically p+1 factorization algorithm, but this might
not be the case.
On the otherhand, I still think p+1 and p-1 are both useful. You just
may end up doing the same test twice, in the worst case.
-- Mika
------------------------------
From: [EMAIL PROTECTED] (those who know me have no need of my name)
Subject: Re: Security of Centrinity's FirstClass Product
Date: Mon, 29 Jan 2001 13:52:52 -0000
as i said in my other reply:
<953arj$an9$[EMAIL PROTECTED]> divulged:
>I have a message from Centrinity Ltd. (formerly SoftArc) below:
>------------------------
>On 19 Apr 00, Aoife Kelly wrote:
>> Because of the security issues we do not discuss the encryption that
>> is built into FCIS in detail
beware snake oil.
--
okay, have a sig then
------------------------------
** 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
******************************
