Cryptography-Digest Digest #611, Volume #13 Fri, 2 Feb 01 05:13:00 EST
Contents:
Re: Mr Szopa's encryption (was Why Microsoft's Product Activation (Anthony Stephen
Szopa)
Re: Most secure code for US Citizen. (Bill Unruh)
Re: Where is the encryption hardware? (wtshaw)
Re: Where is the encryption hardware? (Paul Rubin)
Re: CipherText patent still pending (Bryan Olson)
Re: I thought that Bob with Red Hat was wrong in his statements in August, 2000 ..
same problem as the CEO of Ericsson had... did not understand ... (wtshaw)
Re: Durstenfeld Transpositions & ARC4 (Benjamin Goldberg)
Re: Durstenfeld Transpositions & ARC4 (Benjamin Goldberg)
Re: Very short redundant serial number (Benjamin Goldberg)
Re: Very short redundant serial number (Paul Rubin)
Re: Breaking OAP-L3 (Richard Heathfield)
----------------------------------------------------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: Mr Szopa's encryption (was Why Microsoft's Product Activation
Date: Thu, 01 Feb 2001 22:45:37 -0800
Taneli Huuskonen wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> In <[EMAIL PROTECTED]> Anthony Stephen Szopa
> <[EMAIL PROTECTED]> writes:
>
> >Taneli Huuskonen wrote:
> [...]
> >>
> >> 2. Assume the cryptanalyst can guess _part_ of the key - the part
> >> that describes how the raw pseudorandom bytes are shuffled after they've
> >> been generated. This could well happen, if the user had originally
> [...]
>
> >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.
>
> Are you claiming it can never happen in practice?
>
> Taneli Huuskonen
>
> -----BEGIN PGP SIGNATURE-----
> Version: PGPfreeware 5.0i for non-commercial use
> Charset: noconv
>
> iQA/AwUBOnYCfl+t0CYLfLaVEQKQ4wCeMG2ol561o8estRl5P7Kjz88rF+kAoPhv
> ArdHeFUrSX805gcqmIUo0M4v
> =25ib
> -----END PGP SIGNATURE-----
> --
> I don't | All messages will be PGP signed, | Fight for your right to
> speak for | encrypted mail preferred. Keys: | use sealed envelopes.
> the Uni. | http://www.helsinki.fi/~huuskone/ | http://www.gilc.org/
Breaking OAP-L3
(I just let my old web account expire and am now using pacbell news
server. Oh, boy.
Seems like some of the news group posts are not here. And I cannot
get some news groups.
But here is to the poster whose post isn't here on pacbell's news
server but that I saw on my old ISP's news server.)
Breaking OAP-L3? What is there to talk about?
If you think you can break it then do so.
Download a copy of OAR-L3 from my web site. Have a friend download
a copy, too.
Then have your friend generate OTP files using a 3000 bit key.
Have your friend use a 500 bit key to scramble the original MixFile
and call this output MixFile1.
Have your friend make a copy of MixFile1 and call it MixFile2.
Have your friend use a substantially different 500 bit key to
scramble MixFile2.
Have your friend make a copy of MixFile2 and call it MixFile3.
Have your friend use a substantially different 500 bit key to
scramble MixFile3.
Then have your friend use a substantially different 1500 bit key to
scramble these three MixFileXs then generate the OTP files. Have
your friend generate 100MB of OTP files.
Have your friend do all this according to the recommended usage.
This entire key and all the OTPs are unknown to you and all the
intervening steps and output files are unknown to you up to this
point.
Have your friend remove and copy 1000 bytes of random numbers from
0 - 255 from the very middle of this 100MBs of OTP files.
Then have your friend give you the first 50MBs and the last 50MBs
but less the 1000 bytes in between.
Simply determine these 1000 bytes that were removed from the 100MBs
of OTP files.
Email me if you can accomplish this feat.
I really don't know of any way for me to get involved in a
discussion of this matter unless someone can prove that they can
accomplish the above.
I don't think any of you has a clue as to how to do this. I
certainly don't.
But good luck, anyway.
AS
(this is as much a test of pacbell's news server as anything else.
bye.)
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: Most secure code for US Citizen.
Date: 2 Feb 2001 07:57:51 GMT
In <95ccgh$5ce$[EMAIL PROTECTED]> Michael Robbins <[EMAIL PROTECTED]> writes:
]Thank you for your answers. Like most users, I had not thought about
]the subtleness of the issues. I was hoping for an easy solution.
]Basically I write computer models as part of my work. I cannot compile
]them completely and I must carry and use source code. What I can
]compile can be decrypted by at least one third party without my control
]since I did not write the virtual machine code algorithm.
I would then suggest that you use an encrypting filesystem-- ie
everything on the disk is stored in encrypted form.
However, once they have the binary code, things become much more
difficult. You could for example store the binary code in encrypted
form, and have a stub ask for a password before decrypting and running
the code. Of course, once decrypted it is on that computer, and so if
they can get at your machine you still have problems.
Ie, you have to set up a realistic threat scenario, and then design your
system to counter that.
Could they get access to your hard disk? If so , use and encrypting file
system. Could they get access to your machine while it is running your
program? They you are in real trouble.
Is it just for transporting the code say on a cdrom that is the problem.
Then encrypt it on that cdrom. Etc.
Most algorithms are more than strong enough for your use. It is the
detailed analysis of the threat model, the design of protections against
those and the implimentation of a "user friendly" (you being the user)
system where your problems lie.
]Should a competitor obtain some or all of my code, he will likely have
]vast resources at his disposal (including a "supercomputer" and several
]Math Phds.), if not an actual knowledge of cryptography.
]I'd like to provide as much protection against reverse engineering as I
]can while limiting the impact on my productivity.
]Naively, I assumed that encrypting the source and data would help but I
]now realize that a skilled person may be able to retrieve valuable clues
]in other ways, be it through traces left on my drive or records left in
]my OS.
]I'm not quite sure the protection is worth the effort. It certainly
]seems like a great deal of work.
Well, that is for you to decide of course. No protection at all of
course means that they have full access. Sometimes some protection, even
if not perfect, is better thannone-- it discourages the opponent.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Where is the encryption hardware?
Date: Fri, 02 Feb 2001 01:59:25 -0600
In article <[EMAIL PROTECTED]>,
remove.nospam.in.address.to.reply wrote:
> With all of the obvious benefits of strong cryptography in preventing
> eavesdropping/identification and providing tamper-resistant
> communications, I have but one question: why are there no consumer
> communications products with real encrypted transmission capabilities?
>
> As anyone knows, any monkey with a scanner and a little patience can
> intercept most un-encrypted civilian communications. Since civilians
> make up the bulk of the "consumer" market, why are telecommunications
> devices such as network interface cards, faxes and cellular phones not
> equipped with encryption hardware? Ed
Simple question with a simple answer: The non-civilian part of out
society knows that encryption can no longer be treated as transparent,
convincing everyone that it is a waste of time. But, given that there is
some really good theory at work in the crypto field, only crippled crypto
has been allowed. How to put a governor, so to speak, on the technology
is at the crux of their acceptance of useful crypto.
--
Some people say what they think will impress you, but ultimately
do as they please. If their past shows this, don't expect a change.
------------------------------
From: Paul Rubin <[EMAIL PROTECTED]>
Subject: Re: Where is the encryption hardware?
Date: 02 Feb 2001 00:31:04 -0800
[EMAIL PROTECTED] writes:
> With all of the obvious benefits of strong cryptography in preventing
> eavesdropping/identification and providing tamper-resistant
> communications, I have but one question: why are there no consumer
> communications products with real encrypted transmission capabilities?
If you don't mean computers (ssh, ipsec, SSL web browsers etc) then
then a few zillion smart cards (the chip in your American Express Blue
card for example) have serious cryptography in them.
> As anyone knows, any monkey with a scanner and a little patience can
> intercept most un-encrypted civilian communications. Since civilians
> make up the bulk of the "consumer" market, why are telecommunications
> devices such as network interface cards, faxes and cellular phones not
> equipped with encryption hardware? Ed
For NIC cards, it's cheaper to do the encryption in host software,
though encrypted cards exist. Some cellular phones are encrypted,
though most use weak encryption because of government pressure.
Faxes and regular phones generally aren't encrypted because they
go over the landline network which is supposed to be secure...
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: CipherText patent still pending
Date: Fri, 02 Feb 2001 08:39:02 GMT
Scott Fluhrer wrote:
> Prichard, Chuck wrote:
> > To update this group on the progress of the CipherText
> > algorithm; [...]
> Glad to hear it. However, to save you the trouble of
> constantly keeping us up to date, the next time we want
> to know, we'll ask.
Hear! Hear!
> Obvious questions:
>
> - Have a credible cryptanalyist studied this algorithm?
> If not, why do you claim it to be secure?
>
> - For that matter, what security claims do you make?
>
> - Where can someone find a non-handwaving algorithm
> description, preferably in mathematical notation? I couldn't
> find any sort of description on your web site.
Good as those questions are, when I read yet another report
of the development of a new symmetic cipher, the first
question I ponder is not one those, or others listed in the
FAQ.
Is is: Why?
Does it solve some problem that other ciphers don't? Can
they prove something interesting about this cipher that is
not true of others? Is there some reason anyone should care?
Are people so mis-informed as to think that a symmetric cipher
for which no one produces an effective attack is an interesting
or novel result? Or that there might be commercial potential
for one? Or that a good learning exercise for a student is to
design a cipher?
--Bryan
Sent via Deja.com
http://www.deja.com/
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Crossposted-To: alt.security,comp.security,alt.2600
Subject: Re: I thought that Bob with Red Hat was wrong in his statements in August,
2000 .. same problem as the CEO of Ericsson had... did not understand ...
Date: Fri, 02 Feb 2001 02:11:37 -0600
In article <95c5q8$ult$[EMAIL PROTECTED]>, Markku J. Saarelainen
<[EMAIL PROTECTED]> wrote:
> P.S. I was so interested why Bill Gates was in Miami in establishing
> their Latin America business approaches and instituting their market
> strategies in spring of 2000, when I arrived here ... I had exactly the
> similar mindset ... so if the U.S. government has been involved with
> Microsoft, they have violated the Economic Espionage Act of 1996 and so
> they are criminals. ......
>
They will remind you that they are the government, so therefore they
cannot be criminals. Henry VIII lives.
As for Gates, like many dirty money gluttons before, he lies to himself
first that the end justifies the means, and lies top everyone else as to
what the end really is. He may even think that his power is absolute, but
it isn't.
--
Sugar coated arsenic is bad for your health.
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: Durstenfeld Transpositions & ARC4
Date: Fri, 02 Feb 2001 09:09:27 GMT
Scott Fluhrer wrote:
>
> <[EMAIL PROTECTED]> wrote in message
> news:95d2dm$qk7$[EMAIL PROTECTED]...
> > In article <94r7tp$ei7$[EMAIL PROTECTED]>,
> > "r.e.s." <[EMAIL PROTECTED]> wrote:
> > > "Terry Ritter" wrote...
> > >
> > > | >Also, is ARC4's byte-stream generator adequate as a CSPRNG?
> > > |
> > > | The ARC4 state is awfully small for Dynamic Transposition,
> > > | especially if we shuffle twice. We want more active state in
> > > | the RNG than is used in a single encryption, and probably do
> > > | want at least 128 bits in the block. Since rejection in Shuffle
> > > | (to achieve variable-range) throws away values (and may throw
> > > | away a lot), probably it is not large enough.
> > >
> > > I wasn't proposing to use Dynamic Transposition, but what you
> > > say is interesting -- especially since the Ciphersaber FAQ says...
> > >
> > > "RC4 is a powerful pseudo-random number generator, with a much
> > > bigger internal state, then [sic] the ones that come with most
> > > programming systems."
> > >
> >
> > RC4's internal state is a permutation on 256 elements, so there are
> > 256! possible states. That works out to about 1684 bits. How big a
> > state do you think you need?
>
> Obnit: RC4's internal state is a permutation of 256 elements, and two
> 8 bit variables, giving a total of 256! * 256^2 possible states. You
> have shamefully understated it... (:-)
Obnit Obnit: RC4's keying mechanism avoids a large set of initial
internal states, so that there are fewer than 256! * 256^2 starting
states. The reason for this is to avoid a starting state that is on one
of a particular set of short cycles. It is not known whether there are
any other RC4 short cycles other than the set of short cycles which the
keyschedule avoids.
--
Most scientific innovations do not begin with "Eureka!" They begin with
"That's odd. I wonder why that happened?"
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: Durstenfeld Transpositions & ARC4
Date: Fri, 02 Feb 2001 09:17:29 GMT
Terry Ritter wrote:
>
> On Thu, 25 Jan 2001 19:57:58 -0800, in
> <94qsjr$qfk$[EMAIL PROTECTED]>, in sci.crypt "r.e.s."
> <[EMAIL PROTECTED]> wrote:
>
[snip]
> >Also, is ARC4's byte-stream generator adequate as a CSPRNG?
>
> The ARC4 state is awfully small for Dynamic Transposition, especially
> if we shuffle twice. We want more active state in the RNG than is
> used in a single encryption, and probably do want at least 128 bits in
> the block. Since rejection in Shuffle (to achieve variable-range)
> throws away values (and may throw away a lot), probably it is not
> large enough.
The purpose of having a particular size state PRNG is to allow every
possible permutation to be a possible result of our PRPG (psuedo random
permutation generator). No significant change is made to the size of
the range of possible permutations by double shuffling, so there's no
reason to require a larger PRNG state if double shuffling is used.
--
Most scientific innovations do not begin with "Eureka!" They begin with
"That's odd. I wonder why that happened?"
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: Very short redundant serial number
Date: Fri, 02 Feb 2001 09:30:30 GMT
[EMAIL PROTECTED] wrote:
>
> In article <[EMAIL PROTECTED]>,
> Paul Rubin <[EMAIL PROTECTED]> wrote:
> > [EMAIL PROTECTED] writes:
> >
> > The table just lets you do a bunch of these operations in one step,
> > but you don't need it.
> > Ross Williams has a very thorough explanation of CRC calculation on
> > a page somewhere that you can probably find with a web search.
>
> Thanks, this is helpfull. I will try your reference, and I have
> another here by Terry Ritter. My only real remaining theoretical
> question is whether I can mod 100 a 16bit CRC without destroying the
> CRC properties, when the input data is only two digits. I have the
> 16bit CCITT poly, but 7 and 8 bit variants are hard to come by. There
> is one for you math guys.
I'm not sure if this retains the properties of the CRC, but you could
take the 16 bit CRC, and truncate to 8 bits.
As to turning it into 2 base 10 digits... Why not instead turn it into
2 base 16 (hexadecimal digits)?
> > The reference to Numerical Recipes about using the D10 group sounds
> > interesting and worth checking out. I have that book but don't
> > remember anything about it.
>
> Indeed, it looks interesting, but I don't have the book and could do
> without the tables. Besides, a solution in hand is better than two on
> the shelf. :-)
--
Most scientific innovations do not begin with "Eureka!" They begin with
"That's odd. I wonder why that happened?"
------------------------------
From: Paul Rubin <[EMAIL PROTECTED]>
Subject: Re: Very short redundant serial number
Date: 02 Feb 2001 01:36:37 -0800
[EMAIL PROTECTED] writes:
> Fair enough, but can anyone point me to a very small implementation of
> a 2 digit (basically 3 or 4 bit) CRC? I can't afford the table used in
> the 32bit version I have handy, and anyway it would be pointless to
> generate a 32bit CRC and then mod 100 it.
Actually, this stuff about CRC's is ridiculous too. The CRC is just
a remainder mod some polynomial. But instead of a polynomial you can
use an arithmetic remainder. E.g.
N = number up to 100
first check digit = N % 9
second check digit = N % 8
So there are 72 possible combinations of check digits. The only way
you can get a valid checksum for the wrong input is if the wrong input
is the right input +/- 72. The first check digit will never be 9 and
the second will never be 8 or 9, that shouldn't matter.
------------------------------
Date: Fri, 02 Feb 2001 09:35:49 +0000
From: Richard Heathfield <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,alt.hacker
Subject: Re: Breaking OAP-L3
Anthony Stephen Szopa wrote:
>
> Tom St Denis wrote:
> >
<snip>
> >
> > And BTW no one is going to download your .exe and run them. Provide clear
> > concise papers describing your algorithms and we shall have a go at it.
> >
> > Why can't you do things like the group has been asking (for a year!).
> >
> > Tom
> >
> > Sent via Deja.com
> > http://www.deja.com/
>
> I have. There are a total of three pages. That's all.
>
> They are the Theory and Processes I & II web pages in the Help
> Files at http://www.ciphile.com.
>
> I realize this is all too difficult locate and read.
No no no, I found the pages all right. Reading them was okay too, at
first. But, the more I read, the more I laughed. Surely you couldn't
really be seriously proposing such terribly slow entropy generation?
Surely you couldn't seriously expect sci.crypt to plough through all
your user-docs verbiage?
Do you really think people like Doug Gwyn and Bob Silverman need binary
arithmetic explained to them?
Let me give you an example of how easy it is to Do The Right Thing. I,
too, have designed a cryptographic algorithm. I make no great claims for
it. But I do know how to describe it simply. I'll show you. (This is
from memory. I might have got the details slightly wrong. Irrelevant.)
CDX-2 is a block cipher, where the blocksize is equal to the filesize.
:-)
for i = 1 to keysize
{
for j = 1 to plaintextsize
{
C[j] = S_Box[P[j]]
}
rotate entire block by LUT[K[i]] bits
for j = 1 to plaintextsize
{
C[j] = C[j] ^ K[j % keysize]
}
}
(LUT == LookUp Table)
THAT'S IT. That's all there is to it.
And if people don't understand my description, I will consider it my
failing, not theirs, and I will publish a clarification.
Now, my algorithm is very simple. It is probably flawed. I have
published the source code to it on my Web site, so that people here can
download it, study it, and use it to generate ciphertext so that they
can try to rip it apart. I don't suppose they want to, particularly, but
they can if they like. I've made it easy for them.
Your algorithm may well be more complicated than mine, so it might take
up a few more lines. That's okay. But three pages of sugar-coated
luser-feed is not going to get you any free cryptanalysis. I could
easily generate three pages of text guiding lusers through the process
of using CDX-2, but that's not the kind of documentation sci.crypt want
to see. They want to see your algorithm, out in the open; because, quite
simply, they don't care enough to go digging for 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
------------------------------
** 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
******************************
