Cryptography-Digest Digest #351, Volume #10 Sat, 2 Oct 99 05:13:03 EDT
Contents:
Re: authenticating an executing binary (Todd Owen)
gnu mp library exponentiation function (Amos Waterland)
Re: gnu mp library exponentiation function (Paul Rubin)
Re: Are small block sizes less secure? (wtshaw)
Addition/subtraction mod 256 vs. XOR (Mike DeTuri)
Re: proof ([EMAIL PROTECTED])
Re: authenticating an executing binary ("ME")
Re: Compress before Encryption ("Douglas A. Gwyn")
Re: Ciphers Categorized on Web Site
Re: Twofish and Leapfrog ("Patterson Programming")
Re: Compress before Encryption (wtshaw)
Re: EAR Relaxed? Really? (wtshaw)
Re: Compress before Encryption ("Richard Parker")
Re: EAR Relaxed? Really? (wtshaw)
Re: EAR Relaxed? Really? (wtshaw)
Re: EAR Relaxed? Really? (wtshaw)
----------------------------------------------------------------------------
From: Todd Owen <[EMAIL PROTECTED]>
Subject: Re: authenticating an executing binary
Date: Sat, 02 Oct 1999 11:30:26 +0800
Tom St Denis wrote:
>
> If an illegitamate user can get info they shouldn't simply by recoding the
> program you have to rethink your crypto. What you are aiming at is security
> thru obscurity which we all know is not possible. You should rely on the
> user having some private key info THAT THEY WANT TO KEEP. For example I
> don't want to give out my l/p for my ISP because I want my access and not
> give it out. If for example by giving out my l/p I don't lose anything I
> would.
>
> Tom
the problem is that isn't really any data to protect, and its not
illegitimate users who be motivated to modify the program, but
legitimate ones! The server wants to know that no features have been
disabled in the client program. An example might be something like the
"go!zilla" download program (www.gozilla.com), which I hear is available
free, but displays 3rd party advertising banners as it runs - imagine if
ftp sites refused to talk to the gozilla client if it had been patched
in any way, eg adventising disabled! Scary I know!
Normally in crypto you don't care how the program runs, as long as it
produces the right output. If I wrote a program, and somebody else
wrote a different program which served the same purpose (eg used the
same network protocol) but had different features, I wouldn't
care...heck, I'd hope that they would GPL it and release it to the
public. (NOTE: the case is a bit different with crypto software,
because if private data is at stake you'd have to worry about how
trustworthy the clone program is). But for the hypothetical program in
this post, knowing the protocol isn't enough. It must:
a) be exactly the right binary file
b) be actually _running_ the file
Perhaps the only way this is possible is with a hardware/OS platform
which can enforce some very serious limitations, otherwise the user just
has too much control. Thanks to Giff for pointing out that even if the
user ran the program unmodified to pass the authentication step, they
could then modify the code in memory.
May have to think about non-software solution to this problem. Eg:
somehow make the feature in question (such as gozilla's advertising)
seem beneficial to the user, so they will not _want_ to disable it.
Still, maybe there's a cryptographic solution waiting to be discovered.
Thanks for the comments ppl have made so far.
Todd.
------------------------------
From: Amos Waterland <[EMAIL PROTECTED]>
Subject: gnu mp library exponentiation function
Date: Sat, 02 Oct 1999 01:35:23 -0500
I post this in the hope that someone in the readership will have had
experience coding mathematics programs with the gnu mp math library.
I am attempting to calculate two to the power of n, where n is a
very
large number required for the generation of a large prime. The problem
that I have encountered is the fact that the only relevant
exponentiation function in the library in question requires a mod
argument, which is not an acceptable solution for my application. Has
anybody else encountered this problem?
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: gnu mp library exponentiation function
Date: 2 Oct 1999 06:58:54 GMT
In article <[EMAIL PROTECTED]>, Amos Waterland <[EMAIL PROTECTED]> wrote:
>I post this in the hope that someone in the readership will have had
>experience coding mathematics programs with the gnu mp math library.
>
> I am attempting to calculate two to the power of n, where n
>is a very large number required for the generation of a large prime.
>The problem that I have encountered is the fact that the only
>relevant exponentiation function in the library in question requires
>a mod argument, which is not an acceptable solution for my
>application. Has anybody else encountered this problem?
If you're trying to generate big Mersenne primes, gnump isn't the
right type of library to use. Ask on sci.math.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Are small block sizes less secure?
Date: Fri, 01 Oct 1999 22:41:05 -0600
In article <7t2s5f$23ei$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
(SCOTT19U.ZIP_GUY) wrote:
> IF you want to calculate it find the number of bits to represent (256!)
> that is the size of key necessiary.
> But it is considered very weak. However maybe you would get
> some dumb person to claim you can only do a dumb blind search
> which is what people seem to claim for any problem in which case
> the sun whould have to burn out before a soluton is found.
>
When keys and blocks are envisioned as being searchable, there is a chance
that the key needed is one of the early ones tried. Fixed blocks as well
as short blocks are weak by definition as compared to alternatives if only
one or two blocks need be solved in a known plaintext attack.
If the breaker can easily reduce his efforts to something automatic, he
has most of the fight already won. It is better to scare him away from
even trying.
--
Still a good idea from Einstein: If you can't explain something clearly to a child,
you do not understand it well enough.
So much for models of trust, they generally are ill-founded.
------------------------------
From: [EMAIL PROTECTED] (Mike DeTuri)
Subject: Addition/subtraction mod 256 vs. XOR
Date: Sat, 02 Oct 1999 07:00:24 GMT
I was wondering if there is any benefit to encrypting using addtion
mod 256 in RC4 instead of the standard XOR. Of course, decryption
would be subtraction mod 256. Has anyone tried this? I've searched
DejaNews but found nothing conclusive.
Thanks,
Mike
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: proof
Date: Sat, 02 Oct 1999 06:56:35 GMT
Thanks
I had read that (n^2-1)(n^2-n) was the answer but I'm interested in the
proof of that solution? I figured that the product is the number of
linearly independent row combinations in the 2x2 matrix (nodula n)..but
thats as far as I got.
In article <[EMAIL PROTECTED]>,
"Robert L. Ward" <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
>
> > In the hill cipher how many 2x2 matrices are invertible over modulo
n?
> > (where n is a prime number)
> >
> > Sent via Deja.com http://www.deja.com/
> > Before you buy.
>
> (n^2-1)*(n^2-n).
>
> Robert Ward
>
>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "ME" <[EMAIL PROTECTED]>
Subject: Re: authenticating an executing binary
Date: Sat, 2 Oct 1999 14:33:18 +1000
We worked with a binary which contains a unique serial number that computes
a checksum for a self check, then computes a different checsum, and submits
it (encrypted) to the server.
The server is able to verify the receved serial number and second checksum
matches those stored. The second checksum is SHA-1. If a match occurs, the
server will continue conversation with the client binary, otherwise, the
server ignores the client.
A flag in the server also allows individual clients to be ignored.
Of course, anyone can use SHA-1 in a spoof program to create a checksum of
the binary and submit it the server, if they can reverse the key agrement
and SHA-1 generation process used in the client - apparently a task of low
to moderate difficulty thses days.
Give up on software software - embedded systems like smartcards are more
reliable at this, and provide longer lasting solutions - software binary
integrity checks ony last a few months at best, while smartcards will
generally last the 2-3 year life of the card.
Lyal
Todd Owen wrote in message <[EMAIL PROTECTED]>...
>hi all,
>
>I'm pretty skeptical about this being possible, but it's an interesting
>concept and I wondered if anybody had any thoughts about it. The
>hypothetical situation is:
>
>A comms link is established between a server, S, and a client program,
>C, running on a remote computer. C is a program (meaning a .exe file,
>for instance) that has been distributed to the user. The server wants
>to verify that C is genuinely the .exe file that was distributed, down
>to the last byte.
>
>This does not mean verifying the program's digest, because you can do
>that without the program actually running. The server wants a guarantee
>that the program, unmodified, is running right at that moment. Clearly
>this would involve some sort of challenge from the server, or a replay
>attack would be easy. It sounds like it would involve not just
>crytography but perhaps also something to do with the platform and the
>OS and the way code executes on it. C has to generate some response
>which could (god knows how) _only_ be generated by an executing,
>unmodified version of the program. And best of all, S needs to verify
>this response somehow.
>
>As I say, it sounds rather tricky. The only (inadequate) substitute I
>can think of is just making the program as complicated as possible, and
>throwing in some checksums for good measure. And I know _exactly_ what
>that constitutes - an open challenge to any cracker with some spare time
>on her hands!
>
>Thanks for getting this far!
>Todd.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Compress before Encryption
Date: Sat, 02 Oct 1999 03:51:09 GMT
"SCOTT19U.ZIP_GUY" wrote:
> ... What the hell is your problem.
I explained that: You're misusing a standard mathematical term,
and an attempt to understand your intent raises the question of
how to accurately formulate the property you're calling "one to one".
> ... The "one to one" means that any file can be run through the
> compressor and and any file can be run through the decompressor
> so that there is a "one to one" relationship.
It can't be the first part of that, which merely says that the
programs accept any old garbage (and presumably output transformed
garbage). And the last part is exactly what is not clearly
expressed.
> I never said it made all files smaller.
I never said you said that. I raised the issue parenthetically
to explain why it wasn't clear what range set you have in mind.
(And since you seem to treat the inverse direction symmetrically,
that means the domain set isn't evident either.)
Maybe somebody else who purports to understand your scheme can
re-express it precisely, in conventional terms, so the rest of
us to whom terms such as "one to one" have their established
mathematical meaning can understand it.
> ... Some one as clever as the NSA might be able reduce an
> encryption to the point of breaking just because some one
> used a bad compression.
It would have to be a *really* bad compression scheme.
(The obvious example is one that outputs a predictable header,
which essentially provides a plaintext crib for every message.
But that's hardly a new observation.)
> If you think it wise that a crypto system has built in features to
> tell if a bad key is used then don't use my compression.
What, pray tell, is a "bad key"? If you mean "weak key" as
in some discussions of DES, it's simpler to use a cryptosystem
that has no weak keys.
> who the hell are you anyway.
A cryptanalyst, among other things.
------------------------------
From: [EMAIL PROTECTED] ()
Subject: Re: Ciphers Categorized on Web Site
Date: 2 Oct 99 03:48:56 GMT
I wrote:
: Today, I took both descriptions and merged them, with the result
: (which now more completely describes what I was thinking of, but which
: is not as readable as I'd like; in the next few days I'll try to
: improve that) in the Fractionation section:
There was another mention of that cipher on the same page, which I left in
with a pointer to where I have moved the merged description, to which I
have finally added an example:
http://www.freenet.edmonton.ab.ca/~jsavard/mi060302.htm
John Savard
------------------------------
From: "Patterson Programming" <[EMAIL PROTECTED]>
Subject: Re: Twofish and Leapfrog
Date: Thu, 30 Sep 1999 10:53:41 -0400
Patterson Programming wrote in message ...
>Yes, if you need a simple 64-bit cipher, you may prefer LeapFrog. And yes,
>my office sent a specification of LeapFrog to Schneier's address, I believe
>in the Fall of 1996. Refs: http://lcweb.loc.gov/copyright registration
>number: TXu 763-698. LeapFrog is not patented.
>
>Regards,
>Patterson Programming
>
>
I need to revise my post. The original reference implementation of LeapFrog
is:TXu 763-698. That code was used only to test the round function, and
would not have been seen by most readers of this group. The secure
implementation is:TXu 876-599. It employs alterations to the key-expansion
code, and whitening. The example someone posted to sci.crypt is the
(probably) secure version. LeapFrog is designed to be a very simple, but
strong 64-bit cipher. The S-boxes alternate each round. The cipher is free
to use, but if you do, please credit the author. If anyone finds a practical
attack, please advise.
Regards,
Patterson Programming
http://merrel.members.atlantic.net
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Compress before Encryption
Date: Fri, 01 Oct 1999 22:54:36 -0600
In article <[EMAIL PROTECTED]>, "Douglas A. Gwyn"
<[EMAIL PROTECTED]> wrote:
>
> To the contrary, I am an opponent of people wasting their time
> on solutions to non-problems. Defenses that make sense only
> against brute-force keyspace search are wasted effort.
If a cipher is good enough where only brute force is considered a viable
means of attacking it, a carefully chosen chained algorithm adds to the
problem for an attacker. Therefore, the resultant ciphertext may stand,
and the effort was not wasted.
--
Still a good idea from Einstein: If you can't explain something clearly to a child,
you do not understand it well enough.
So much for models of trust, they generally are ill-founded.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Crossposted-To: talk.politics.crypto
Subject: Re: EAR Relaxed? Really?
Date: Fri, 01 Oct 1999 23:16:52 -0600
In article <uo6J3.46$[EMAIL PROTECTED]>, "karl malbrain"
<[EMAIL PROTECTED]> wrote:
> Have you `monitored' where these proposals for BACK-DOOR keys, which would
> by necessity remain SECRET for the FBI/NSA, keep coming from???
>
The visable source is L. Freeh, but the reals sources are all who dream of
dungeons and caldrons of oil to the light of flickering torches as
acceptable venues for controlling people's lives through punishment and
fear. Inspiration is much better as it is cheaper, faster, and causes
people to feel better.
--
Still a good idea from Einstein: If you can't explain something clearly to a child,
you do not understand it well enough.
So much for models of trust, they generally are ill-founded.
------------------------------
From: "Richard Parker" <[EMAIL PROTECTED]>
Subject: Re: Compress before Encryption
Date: Sat, 02 Oct 1999 07:55:00 GMT
"Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
> "One to one mapping" (injection) is a standard mathematical term,
> typically taught in high school or even earlier. It means that
> the mapping takes distinct elements in the domain to distinct
> elements in the range. Thus, a "one to one compression" would
> merely produce different compressed outputs for different
> compressed inputs. But *all* lossless compression schemes have
> this property. D.Scott seems to want to describe a different
> property than this, apparently that the mapping is "onto"
> (surjective), although it isn't clear what the range set is.
> (If the domain is V^n for some n, the range cannot be V^n if
> there is *compression*, and if *any* input is truly compressed,
> then *some* input must be *expanded*.)
"Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
> Maybe somebody else who purports to understand your scheme can
> re-express it precisely, in conventional terms, so the rest of
> us to whom terms such as "one to one" have their established
> mathematical meaning can understand it.
Hmm. I'll give it a try.
Let us start with the statement that a compression function is a
function f such that:
f:{0,1}* -> Y
If we define Y as the subset of {0,1}* that is the actual output of
the compression function then any conventional lossless compression
function clearly must be both one-to-one (injective) and onto
(surjective), and thus a one-to-one correspondence (bijective).
On the other hand, if we define Y as {0,1}* then a conventional
lossless compression function is one-to-one (injective) but not onto
(surjective) - and thus not a one-to-one correspondence (bijective).
As I understand it, Scott suggests that his scheme is a bijection from
the set {0,1}* to itself, and thus it is a permutation or symmetry of
the set {0,1}*.
So, it is clear that naming Scott's scheme "one-to-one compression" is
misleading since all lossless compression is one-to-one. A better
name would indicate Scott's belief that his scheme is a permutation or
symmetry of the set {0,1}*. Perhaps "symmetric compression" would be
a better name, although this might be to too easily confused with
symmetric encryption.
Your thoughts?
-Richard
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Crossposted-To: talk.politics.crypto
Subject: Re: EAR Relaxed? Really?
Date: Fri, 01 Oct 1999 23:31:22 -0600
In article <IPaJ3.158$[EMAIL PROTECTED]>, "karl
malbrain" <[EMAIL PROTECTED]> wrote:
>
> wtshaw spoke of gleaning positivity from GOVERNMENT AGENT'S PRACTICE VIZ
> MONITORING. You'll have to ask him for clarification on that one. I stand
> on the BOLSHEVIK position.
>
Word salads are not too attractive. I prefer celery and carrot sticks
myself. If you have questions, try not to be too obscure.
--
Still a good idea from Einstein: If you can't explain something clearly to a child,
you do not understand it well enough.
So much for models of trust, they generally are ill-founded.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Crossposted-To: talk.politics.crypto
Subject: Re: EAR Relaxed? Really?
Date: Fri, 01 Oct 1999 23:39:16 -0600
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Johnny
Bravo) wrote:
>
> It may be important, but would no longer be necessary. Legal is
whatever the
> law says is legal. That is why people are so concerned about this provision.
> We aren't so worried about it being obtained legally, we are concerned
with them
> just fabricating evidence and then just presenting it to the court as
being from
> encrypted data on your computer, without them even proving it was your data in
> the first place since they don't have to disclose how that data was retrieved.
>
Legal is what the courts finally say it is; specific laws don't
necessarilly measure up, and you are should realize that you cannot be
under absoluted compulsion to obey an illegal instruction, current law or
not; it's a moral thing.
Manufacturing evidence is criminal behavior.
--
Still a good idea from Einstein: If you can't explain something clearly to a child,
you do not understand it well enough.
So much for models of trust, they generally are ill-founded.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Crossposted-To: talk.politics.crypto
Subject: Re: EAR Relaxed? Really?
Date: Fri, 01 Oct 1999 23:25:40 -0600
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Jerry Coffin) wrote:
>
> OTOH, this would reveal at least some indication that they were
> capable of analyzing the algorithm in question, which they might not
> want to do either. They might, however, leave the method they used to
> find the key undefined, and let others believe (for example) that they
> just happened to run across a Postit note (or whatever) telling them
> the key...
>
The defence will likely not leave so many stones unturned, as evidence
must be still shown to be accumulated legally, and some methods are
banned.
--
Still a good idea from Einstein: If you can't explain something clearly to a child,
you do not understand it well enough.
So much for models of trust, they generally are ill-founded.
------------------------------
** 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
******************************
