Cryptography-Digest Digest #564, Volume #12 Tue, 29 Aug 00 11:13:01 EDT
Contents:
Re: Future computing power (Ichinin)
Re: Future computing power (Ichinin)
Re: An interesting cryptographic problem ([EMAIL PROTECTED])
A little technical note about intepreters (Runu Knips)
Re: 4x4 s-boxes ([EMAIL PROTECTED])
Reading recommendations on protocol design (Chris Yuen)
Re: R: R: Test on pseudorandom number generator. ("Douglas A. Gwyn")
Re: NEWBIE!!! Zodiac killer's encryption... ("Douglas A. Gwyn")
Re: A little technical note about intepreters (SCOTT19U.ZIP_GUY)
Re: Reading recommendations on protocol design (David A Molnar)
Re: Future computing power (David A Molnar)
Re: Future computing power ([EMAIL PROTECTED])
Re: 96-bit LFSR needed ("Douglas A. Gwyn")
Re: Bytes, octets, chars, and characters ("Douglas A. Gwyn")
Re: Asymmetric Encryption Algorithms (DJohn37050)
Optimal length of the sieve before a Miller-Rabin test ("Pedro Félix")
----------------------------------------------------------------------------
From: Ichinin <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Future computing power
Date: Tue, 29 Aug 2000 03:06:28 +0200
Brian McKeever wrote:
>
> <[EMAIL PROTECTED]> wrote in message news:8oeilk$308$[EMAIL PROTECTED]...
> > In article <[EMAIL PROTECTED]>,
> > [EMAIL PROTECTED] wrote:
> > >
> > > Floating operation: 1/3 = 0,3333333333...
> > >
> > > More terms (Dhrystones etc) can be learned through studying
> > > theory of benchmarking.
> >
> > You are best off doing osmething like a vector projection, dct, etc...
> > that is REAL instead of
> >
> > for a = 0 to 100000000
> > b = c * 1/3;
> >
> > So your speed is in "vector projections",etc per second, something more
> > real and tangible
> >
> > Tom
>
> Are you really telling this guy, who obviously knows more about benchmarking
> than you, that he's using the wrong units?
It was just an example.
/Ichinin
------------------------------
From: Ichinin <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Future computing power
Date: Tue, 29 Aug 2000 03:19:13 +0200
Guy Macon wrote:
> In my job (toy designer), I use what amounts to a 6502 running at 3 to 10
> Mhz and costing well under a dollar for everything - CPU, RAM, ROM, clock
> circuit, PWB - the whole computing subsystem.
How much power can you squeese out of a 6502 with todays technology ?
(would be intresting to know)
(Have a friend who's talking about the same things as you, but he's a
more Zilog orientated.)
Regards,
Glenn
(Yup, i had a C64 and a Vic20 :o)
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: An interesting cryptographic problem
Date: Tue, 29 Aug 2000 13:42:32 GMT
In article <[EMAIL PROTECTED]>,
Daniel Newby <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> >
[snip]
> Let me succinctly state the problem: users are granted RDBMS access
> permissions they should not have, in order that flawed applications
may
> run.
>
> There it is. No amount of talking can cover up that ugly fact. The
> user can destroy and forge data, but they should not be able to.
>
> You go on to say what the consequences are:
> > Because the user can easily access the database using third-party
query
> > and reporting tools, any application-level security is easily
bypassed.
> > This leads to serious security weaknesses and potential audit
> > nightmares.
>
> You use the phrases "serious security weaknesses" and "potentional
audit
> nightmares". You didn't say, but I'm assuming the database contains
> corporate financial information (or inventory and sales data, which is
> about the same). Presumably the sort of information that gets used
> in SEC filings, and quarterly reports to investors. The sort of
> information that, if it is falsified, will lead to fines, bad
publicity,
> or even prison sentences. Not to mention the straightforward risk of
> bankruptcy if somebody spends money that isn't there.
>
> In a later posting, you said:
> > DES is more than sufficiently secure for this
> > application, which is not 'mission-critical'. DES in CFB mode has
the
> > advantage that successive encryptions of the same plaintext produce
> > different encrypted text. This makes dictionary attacks much less
easy.
>
> How do you go from "audit nightmare" to "not mission-critical"?!
> "Mission-critical" doesn't mean the world will end if it fails, it
just
> means the organization's mission is at stake. Financial and operating
> data normally *is* mission critical, especially if it is used as a
> basis for government financial filings. Maybe it's time to go read
that
> mission statement? ;-)
>
> You need to do some threat modeling. If the threat is accidents
> committed by benevolent employees, then just about any solution will
> work. If the threat is deliberate fraud by motivated opponents, and
> there are large financial and legal stakes, then half-measures are
> worthless: someone will eventually do the necessary work to break
> them.
>
> In fact, a half-measure will be worse than no security. Few people
> are knowledgable about security. In their ignorance, many people will
> therefore rely on the half-assed security as if it were real security.
> When the inevitable violation occurs, they will be shocked and angry.
> The recriminations and lawyers will fly; your product will be blamed
> both for having poor security and for being violated. If the data
> is as important as I suspect it is, careers and businesses could be
> destroyed.
>
> Unless you implement complete end-to-end transaction security, your
> only security is illusions. Worse, the amount of effort needed to
> lift the veil of illusion is unknown and probably very small.
Breaking
> your proposed security DLL would be trivial -- there are people who
> do that sort of thing for a hobby. Not to mention the fact that
> any network sniffer could just grab the encrypted authentication data
> {u',p'} right off the wire -- no programming ability necessary.
>
> If you think the stakes are low enough, feel free to use illusory
> security. But if the stakes are high, you're just sticking your
> head in the sand.
These are absolutely accurate comments and I cannot argue with your
conclusions. Having said that, we face the reality that protecting
existing LOB applications does possibly require some compromise, in the
same way that presumably your home is secured against likely threats
(amateur burglars) but not professional thieves, since they know how to
get round most locks and alarm systems.
In this case the application needs to be shown to be 'acceptably
secure'. That is, given that the data is not highly sensitive, nor is
it used for operational matters - i.e, it is analytical information
derived from data flows that are processed elsewhere.
In other words, tampering with it won't achieve much, but on the other
hand the company's auditors require that the system be reasonably
secure i.e the front door can't be left unlocked. So I am talking about
the company saying 'our auditors require that this system be reasonably
secure' but at the same time saying 'of course, we realize this data
isn't actually highly sensitive and that's why we aren't requiring
biometric or challenge/response type security'.
Hence a security system that can be shown to be designed with due care
and diligence to repel a range of perceived attacks (only) would be
acceptable to the company and its auditors. This is particularly true
because the systems are not connected to the outside world in any way
e.g the Internet.
You note that the ASK is easily recovered. I noted this vulnerability
but recall that this does not allow you to forge attack credentials
since you cannot retrieve the SSK.
I cannot see any easy way of securing the ASK since any retrieval API
must have implicit knowledge of how to retrieve it. Thus, any further
encryption is simply having a key to a cupboard in which there's a key
to the safe ... etc. This is no more secure.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Tue, 29 Aug 2000 15:53:13 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: A little technical note about intepreters
Jeffrey Williams wrote:
> Not that long ago, I was told by a high school computer
> science teacher that putting comments in code was very bad
> because it made the code run slower (true enough, but only
> if you're using an interpreter).
I've to add that this is only true if you use a really
slow intepreter, because the fast ones (examples: perl,
xscheme) will transform the source representation into
some bytecode, which is also not influenced by comments.
And if one uses the slow intepreters, speed should
really be no issue. A good example for a slow intepreter
are the traditional text shells comming with unix
(/bin/sh, /bin/ksh, /bin/bash, /bin/csh, /bin/tcsh or
/bin/zsh). Shell programs contain masses of calls to
external programs which each require a call to fork()
and exec(), both calls are VERY expensive, far more
expensive than skipping over a comment in code.
Therefore you should put comments everywhere, no matter
what you're programming.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: 4x4 s-boxes
Date: Tue, 29 Aug 2000 13:56:39 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Mack) wrote:
<snip>
>
> You can also use the maximum hamming weight to a linear function
> which is quicker to calculate. Extending this to an s-box is a bit
> trickier but very useful.
Yeah, what you have todo is find all linear functions (there are quite
a few) then all you do is take your function and xor it against the
linear ones. The WT is a relatively fast test.
> bent is usually used to refer to functions which have non-linearity
> which is maximum. They only occur on functions of 2n variables
> and are not balanced. You appear to be refering to nearly bent
> functions.
Ahem, according to "Perfect nonlinear Sboxes" by Kaisa Nyberg from
Eurocrypt '91, we have and I quote.
2. Bent Functions
Let q be a positive integer and denote the set of integers modulo q by
Zq. Let "u = e^((2*pi*i)/q)" be the q'th root of unity in C, where i =
the imaginary number sqrt(-1). Let f be a function from the set Zn/q
of n-tuples of integers modulo q to Zq. Then the Fourier transform of
u^f is defined as follows
F(w) = 1/sqrt(q^n) * sum of (x in Zn/q) (u^(f(x) - w.x), for all w in
Zn/q.
Definition 2.1: A function F: Zn/q -> Zq is bent if |F(w)| = 1 for all
w.
---endquote--
In this case for a 4x4 function we find that "1/sqrt(q^n)" is "1/sqrt
(2^4)" which is "1/4". Which means a WT output of '4' times 1/4 gives
us "1" and we have a bent function.
>
> {3,13,6,14,2,0,15,12,1,5,10,7,4,11,8,9};
>
> This is taken from Construction of DES-like S-boxes based on
> Boolean functions satisfying the SAC by Kwangjo Kim.
>
> Which are the S^2 s-boxes. This is line 2 of the S3-box.
>
> The definition of non-linearity is the hamming distance
> from the closest affine function. (Ruepple's criterion)
>
> This has non-linearity of 4 and satisfies the SAC for
> each of the boolean functions that are used to construct
> it.
>
> Its inverse
>
> 5 8 4 0 12 9 2 11 14 15 10 13 7 1 3 6
>
> has nonlinearity of the constituent boolean functions
> 2 4 2 4
>
> and none of the constituent functions satisfy the SAC.
>
> So no the inverse does NOT have the same non-linearity.
>
> proof by counter example
I stand corrected. However, the differential table can be simply
transposed for the inverse, so I was close to being right :-)
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Chris Yuen <[EMAIL PROTECTED]>
Subject: Reading recommendations on protocol design
Date: Tue, 29 Aug 2000 21:37:35 +0800
Dear all,
Right now I'm looking for some materials on protocol design(in the
computer security area, not network protocols I'm referring to). Could
anyone of you recommend me some books, or materials(preferably online)
that contain such info? Thanks. Some introductory material would
probably
be very useful.
Best,
Chris
P.S.: I hope this is the correct n/g to ask such a question, if it turns
out the other way round, pls let me know ;)
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: R: R: Test on pseudorandom number generator.
Date: Tue, 29 Aug 2000 13:51:24 GMT
"Douglas A. Gwyn" wrote:
> number of d.f. is just one less than the number of "tests",
Oops, I've been working with contingency tables too long.
Since the "expected value" is derived from theory and not
from the observed data, there is no need to subtract 1; the
number of d.f. is equal to the number of test values. That
slightly affects the Q-values:
df = 10
q(CryptGenRandom) = 0.4346 # Prob(chisq would be that large by chance)
q(URAND) = 0.0000 # Prob(chisq would be that large by chance)
Which makes the contrast between the two methods even greater
than I previously reported.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: NEWBIE!!! Zodiac killer's encryption...
Date: Tue, 29 Aug 2000 13:59:37 GMT
"John C. King" wrote:
> The second cipher has similar ciphertext symbols ...
But not exactly the same set. Note that the Zodiac killer
apparently had arranged his previous cipher alphabet with
similar subclasses of symbols adjacent. If the same thing
were done for the second cipher, it could facilitate
cryptanalysis. Unfortunately the message is too short to
crack without some such additional structure.
> Graysmith claims to have solved the second large cipher
> and gives a "solution", however he provides no methodology
> and it appears to be a bogus solution with lots of anagramming.
It's definitely a bogus solution, similar to the "Bible Code",
Collomb's Kryptos, or Bacon extracted from Shakespeare.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: A little technical note about intepreters
Date: 29 Aug 2000 14:13:40 GMT
[EMAIL PROTECTED] (Runu Knips) wrote in <[EMAIL PROTECTED]>:
>Jeffrey Williams wrote:
>> Not that long ago, I was told by a high school computer
>> science teacher that putting comments in code was very bad
>> because it made the code run slower (true enough, but only
>> if you're using an interpreter).
>
>I've to add that this is only true if you use a really
>slow intepreter, because the fast ones (examples: perl,
>xscheme) will transform the source representation into
>some bytecode, which is also not influenced by comments.
>
I have to add this transformation does not occur in
zero time. So the adding of comments does slow the code.
One thing from my long career programming I have even run
into compliers that have bugs in them due to the effects
of comments. This should not happen but it does.
Also as far as maintaning code often a bad comment
can lead the maintainer astray so that the code will
remain buggy for years. For better to use comments that
tell what comes in a routine and what goes out. Then a
few comments as to what method but don't get excessive
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
http://members.xoom.com/ecil/index.htm
Scott rejected paper for the ACM
http://members.xoom.com/ecil/dspaper.htm
Scott famous Compression Page
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
"The road to tyranny, we must never forget, begins with the destruction
of the truth."
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: Reading recommendations on protocol design
Date: 29 Aug 2000 14:17:45 GMT
Chris Yuen <[EMAIL PROTECTED]> wrote:
> Dear all,
> Right now I'm looking for some materials on protocol design(in the
> computer security area, not network protocols I'm referring to). Could
> anyone of you recommend me some books, or materials(preferably online)
> that contain such info? Thanks. Some introductory material would
> probably
> be very useful.
Avi Rubin had a course on protocol design at NYU a few years back.
The reading list and problem sets are on the web and they are very
good. I think it's www.avirubin.com/ and look under courses taught.
Another paper I like is "Robustness Principles for Public Key
Protocols" by Ross Anderson (and someone else - Needham?).
Google search for Ross Anderson and you'll find it.
I'm not familiar with any books specifically in this area; would like to
hear of any.
Thanks,
-David
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: Future computing power
Date: 29 Aug 2000 14:19:49 GMT
Guy Macon <[EMAIL PROTECTED]> wrote:
> In my job (toy designer), I use what amounts to a 6502 running at 3 to 10
> Mhz and costing well under a dollar for everything - CPU, RAM, ROM, clock
> circuit, PWB - the whole computing subsystem. A Dallas DS80C320 is an
> 8051 that does 10 MIPs if you overclock it from 33 Mhz to 40 Mhz
> (see [ http://www.systronix.com/home.htm ].) With the right software,
> you could put together a quite powerful specialized crypto computer at
> a very low cost using large numbers of cheap processors.
Suddenly I have a vision of Furbies chattering keys in their sleep.
Sort of like the Chinese Lottery, but without the set top boxes.
-David
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Future computing power
Date: Tue, 29 Aug 2000 14:37:49 GMT
In article <[EMAIL PROTECTED]>,
Anders Thulin <[EMAIL PROTECTED]> wrote:
> That first measure 'cycle per opcodes' seems to be one that decides
> whether or not the one you mention are relevant. If you have only one
> or a few cycle per opcodes, there won't be much reason to have a
deeply
> pipleined architecture.
>
You might *need* to have a deep pipeline to get the signals needed
complete an opcode with 1 cycle (in real time) of effective throughput
where they need to go. An MPU with a shallow pipeline might not be able
to ramp to high clock speeds OR might have multiple cycle opcode
execution times.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: 96-bit LFSR needed
Date: Tue, 29 Aug 2000 14:04:18 GMT
[EMAIL PROTECTED] wrote:
> I am trying out the stream cipher where I take three bytes from the
> LFSR in the form (a, b, c) and return (((a+1)(b+1)) mod 257)+c) mod 256
> as the stream output.
Why? And how does the plaintext enter into this?
------------------------------
Crossposted-To: comp.lang.c
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Bytes, octets, chars, and characters
Date: Tue, 29 Aug 2000 14:28:57 GMT
Richard Bos wrote:
> "Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
> > I don't know where you got your copy of ISO/IEC 9899:1999
> > but this specification is definitely in the standard, in
> > subclause 7.18.1.1 (and reflected in 7.18.2.1).
> I haven't got the actual Standard, I've got the final draft.
Then you don't have the correct spec, which is as I said.
> ... that would require several two's-complement types even
> on machines where all other types use a different representation.
And you don't understand the one that you have; exact-width
types were never *required* for conformance, in any of the
drafts nor in the final standard.
The change was made in response to review comments which
pointed out that exact-width types weren't very useful
unless they had more guaranteed properties than just
their width. As shepherd for that part of the standard,
I was obligated to present the suggested change, and was
somewhat surprised when there were no strong objections.
Traditionally, C implementations pick the properties for
the standard types (subject to some minimum-width
constraints) and portable programs have to go through
contortions to determine their properties in order to use
the most appropriate types. The <stdint.h>/<inttypes.h>
approach adapts existing practice in order to address some,
but by no means all, of the issues involved in portably
specifying properties for integer types. A more thorough
solution, dealing with endianness etc., was sketched by
Frank Farance, but absence of practical experience with
such a scheme prevented it from being adopted for C99.
It is possible that something along those lines might
appear in a future revision of the C standard, if in the
interim there are some experimental implementations to
let us see how well it works in practice.
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: Asymmetric Encryption Algorithms
Date: 29 Aug 2000 15:01:37 GMT
A few comments on David's opinions.
1) The NIST metric is based on TIME, which might be considered conservative but
I do not consider simplistic.
2) NIST said this to ANSI X9, which is where many millions of dollars are moved
electronically every hour and it is appropriate to be conservative. That is
something that is appropriate to protect $50 may be a lot quicker and simpler
than something used to protect lots of money.
Don Johnson
------------------------------
From: "Pedro Félix" <[EMAIL PROTECTED]>
Subject: Optimal length of the sieve before a Miller-Rabin test
Date: Tue, 29 Aug 2000 16:00:54 +0100
I apologise if this question was already overdiscussed in this newsgroup,
however I could not find any post on the subject.
On the context of primality testing it is usual to precede a probabilistic
test, such as the Miller-Rabin, with the divisibility test of the candidate
by all the primes lower than a bound B. My question is how to obtain the
optimal value of B. From a quick analysis I know that it depends on:
the cost D of a division;
the cost E of a Miller-Rabin iteration (approx. equal to the cost of an
exponentiation)
the probability that a candidate is coprime to all the primes in the
sieve (Q(B) \approx 2e^{-\gamma}/log(B))
Some authors give heuristic bounds (such as B=1000), based on the curve
Q(B); other sugests a experimental tuning.
I know that the reference: Brandt, Damgard and Landrock, "Speeding up prime
number generation", Asiacrypt 91 discusses this subject but I'm unaible to
obtain a copy of it.
a) Are there any references (with preference to the ones electronically
available) with a analysis of the subject.
b) I see some dificulties on a experimental tuning, due to the number of
tests that have to be done before we get some aceptable statistic. I'm I
missing something here?
Once again I apologise for posting a (probably) overdiscussed question and
thank any reply.
Any other thoughts on this topic are welcomed
Pedro Félix
------------------------------
** 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
******************************
