Cryptography-Digest Digest #356, Volume #13 Sun, 17 Dec 00 21:13:01 EST
Contents:
Re: Protocol for computer go (Francois Grieu)
Re: does CA need the proof of acceptance of key binding ? (Mok-Kong Shen)
Re: Encryption detail added to cipher page ("r.e.s.")
Re: How does public key crytography work, mathematically? (Marc)
Re: Securing credit card numbers (Marc)
Re: Elliptical Curve Math Question (Mike Vaughn)
Re: Elliptical Curve Math Question (Paul Schlyter)
Re: Visual Basic Source Code (Paul Schlyter)
Re: Visual Basic Source Code (Paul Schlyter)
Re: Use of multiplexing (Benjamin Goldberg)
Re: Encryptian of data over radio transmission ("madcow")
Re: Array shuffling (Benjamin Goldberg)
----------------------------------------------------------------------------
From: Francois Grieu <[EMAIL PROTECTED]>
Subject: Re: Protocol for computer go
Date: Sun, 17 Dec 2000 22:52:02 +0100
Benjamin Goldberg <[EMAIL PROTECTED]> wrote (ecrivait) :
> Instead of having the opponent's move generate an interrupt, require
> that the program poll some particular function to see if the opponent
> has moved. In creating a log of the game, for the replay version, we
> can say: poll_opponent() returns false exactly N times, before the
> opponent moved.
> Since we don't ever look at our own computer's clock, only the messages
> from the referee, we always do a deterministic number of computations,
> which can thus be repeated by the replay computer.
There is a problem with this approach. As a proof of concept,
assume the play and replay program are genuinely deterministic
and running the same code on identical brand CPU, except for
clock speed, and a human changes the clock speed of the play
machine while running. The programs sends queries every say
1 million instructions. If the adversary has played after say
10 queries, the program plays defensively, else it plays
offensively. A human looks at the game, and when it thinks the
program has a good position, slows it down. It will start
to defend (sensing the adversary is fast). The replay program
will automatically be kept in sync by the log.
Besides, there is no way you'll prevent the play program from
beeing non-deterministic and reading wall clock time. In real
life, the above cheating scenario would be implemented using
a fixed-speed CPU, and changing the pool rate in software, say
according to the caps-lock key.
Francois Grieu
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: does CA need the proof of acceptance of key binding ?
Date: Sun, 17 Dec 2000 23:23:00 +0100
[EMAIL PROTECTED] wrote:
>
> sorry for the confusion: I assume the 'proof of acceptance for the
> key binding' is the applicant's analog signature or analog fingerprint
> on an agreement that specifies the binding of the applicant's unique
> identity to a public key.
I guess the issue is analogous to one's obtaining unique
account numbers at one's bank, isn't it? Otherwise what
significance would the function of CA have?
M. K. Shen
------------------------------
From: "r.e.s." <[EMAIL PROTECTED]>
Subject: Re: Encryption detail added to cipher page
Date: Sun, 17 Dec 2000 14:44:25 -0800
"Jim Gillogly" <[EMAIL PROTECTED]> wrote ...
| "r.e.s." wrote:
| > I was questioning the interpretation of IC in terms of keyword
| > length, if the keyword were not being used periodically.
|
| Having an IC larger than 0.038 with English plaintext and lots of
| ciphertext strongly suggests that not very many alphabets are being
| used, whether they're being used periodically or some other way.
| I would expect a running key cipher with a pseudo-random key to use
| all 26 alphabets, and that would have a smaller I.C. The larger
| than expected IC doesn't say anything about periodicity, but it
| does strongly suggest few different alphabets are used.
Afaics, there's no reason to conclude that some of the 26
alphabets are not being used. It's just that some of them
are likely to have been under- or over-sampled.
| It could
| (barely) be Gromark-like (Gronsfeld with fibonacci-style running
| key), or another fibonacci type with less than a 26-character
| alphabet. However, I suspect periodic is more likely, given the
| description.
|
| In order for you to make a case for your running key model being
| possible, you need to explain the IC.
If all 26 letters were sampled uniformly at random, we would
expect an IC tending toward 0.038. Larger IC values would
be the tendency if the sampling were not uniform, such as
might occur with a biased running key.
--r.e.s.
------------------------------
From: [EMAIL PROTECTED] (Marc)
Subject: Re: How does public key crytography work, mathematically?
Date: 17 Dec 2000 23:10:24 GMT
>assume that the source of your program is available, so wouldn't someone
>simply be able to look at your two equations and derive one key from the
>other? That can't be right though... How does it work?
In public key cryptography, one has all equations necessary to
derive one key from the other. All is known and proven. The
only caveat is that a function has been chosen that is particularily
difficult to solve. Namely, it is trivial to multiply two
large prime numbers, but it is impossible to factor the result
back into the initial numbers. I can factor 6 back to 2 * 3, but
I can't for primes with 300 decimal digits, and todays' computers
can't either. Can you?
------------------------------
From: [EMAIL PROTECTED] (Marc)
Subject: Re: Securing credit card numbers
Date: 17 Dec 2000 23:10:30 GMT
>card number to be unique, I mean that the encrypted string for one card
>is the same in all cases –this means that we cannot use random salt
>values to help the encryption-.
>- Use 3DES to encrypt the credit card number.
Since you consider symmetric cryptography you aparently have
a trusted computer that can store the keys. Why don't you then
salt the encryption with the result of another encryption?
Ie encrypt last 8 bytes with "salt-key". Form new message with
these 8 bytes plus the full credit card number, encrypt this
new message with 3DES database key.
Another aspect: if you store many numbers but never extract
one back except when fraud has happened, you can use public key
encryption. The server then can store new numbers into the
database. But even if the server + database is stolen, the
thieve can not decrypt a single card number (because the
secret key is not there).
>- Given that the possible Credit Card numbers are only around 300 x
>10^12, is it easier to break 3DES and find the key? If so, is it true
>that adding some random data to the card number will avoid this
>weakness?
I rather think that the attacker will skip your database and
generate card numbers directly.
------------------------------
From: Mike Vaughn <"vaughnmt"@@@home.com>
Subject: Re: Elliptical Curve Math Question
Date: Mon, 18 Dec 2000 00:34:49 GMT
I ran the first equation through an equation solver that I found on the net, and
thought that it was a simplified version of the former. Obviously it is not, so
I will forgo the latter and stay with the original y^2 = x^3 + A x + B. I am not
using this for cryptology so I am not concerned with points and finite fields. I
have my own need of it for my own little project. I would like however, to be
able to solve for X once A, B and Y are known. I would greatly appreciate it if
someone could help me out with this. My math skills are nowhere near as good as
yours. This is why I posted here, because I respect the knowledge that shows
itself here.
Again,
Many Thanks
Mike Vaughn wrote:
> Hi,
> I wish to use the following formula to generate elliptical curves:
>
> y^2 = x^3 + A x + B
>
> or similarly:
>
> y = sqr(B + A x + x^3 )
>
> From what I've been able to learn is that these are fairly standard formulas
> for such.
>
> I can play around with A, B and X all day to solve for Y, that part is easy.
> The problem that I am having is that I am having a dilly of a time solving
> for X once A, B and Y are known.
>
> Assuming that:
>
> A = 10
> B = 20
> X = 8
>
> Y = Sqr(B + (A * X) + (X ^ 3))
> Y = Sqr(20 + (10 * 8) + (8 ^ 3))
> Y = 25
> =============================
>
> Inversly:
>
> A = 10
> B = 20
> Y = 25
>
> Y = Sqr(B + (A * X) + (X ^ 3))
> 25 = Sqr(20 + (10 *X) + (X ^ 3))
> X = ???
>
> Can anyone help with this? The solution for X must not only solve for this
> set of variables but for any reasonable values A, B and X.
>
> Thanks!
------------------------------
From: [EMAIL PROTECTED] (Paul Schlyter)
Subject: Re: Elliptical Curve Math Question
Date: 18 Dec 2000 01:14:04 +0100
In article <91ipck$tmr$[EMAIL PROTECTED]>,
Simon Johnson <[EMAIL PROTECTED]> wrote:
> I am told that there is a general equation for cubic equations such
> that you can find x from y BUT i don't know what it is.
Suppose we have:
y = A x^3 + B x^2 + C x
Divide by A, set y/A = -r and we get:
x^3 + B/A x^2 + C/A x + r = 0
Set p = B/A, q = C/A:
x^3 + p x^2 + q x + r = 0
Substitute for x the value X - p/3 and we get:
X^3 + a X + b = 0
where a = 1/3 ( 3 q - p^2 )
b = 1/27 ( 2 p^3 - 9 p q + 27 r )
This is the "normal form" of a cubic equation. Now compute:
U = b/2
V = b^2/4 + a^3/27
A = cbrt( -U + sqrt(V) )
B = cbrt( +U + sqrt(V) )
where cbrt() is the cube root and sqrt() is the square root
The three solutions of X will now be:
X1 = A + B
X2 = -(A+B)/2 + (A-B)*sqrt(-3)/2
X3 = -(A+B)/2 - (A-B)*sqrt(-3)/2
where sqrt(-3) of course is i*sqrt(3) where i=sqrt(-1)
If p, q and r are all real then:
if V > 0 there is one real root and two conjugate complex roots
if V = 0 there are three real roots of which at least two are equal
if V < 0 there are three real and unequal roots
--
================================================================
Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
e-mail: pausch at saaf dot se or paul.schlyter at ausys dot se
WWW: http://hotel04.ausys.se/pausch http://welcome.to/pausch
------------------------------
From: [EMAIL PROTECTED] (Paul Schlyter)
Subject: Re: Visual Basic Source Code
Date: 18 Dec 2000 01:14:35 +0100
In article <Z%5%5.7467$[EMAIL PROTECTED]>,
<[EMAIL PROTECTED]> wrote:
> Paul Schlyter <[EMAIL PROTECTED]> wrote:
>>> You ever try and build an OS in cobol? What about python? sh? perl?
>>> forth, pascal, logo, prolog, fortran?
>>
>> forth gets quite close though: the forth OS is in large part written
>> in forth.
>
> And JavaOS is written completely in java.
Including the Java bytecode interpreter? <g>
> So by your definition it's more of a "real" language than forth? This
> is exactly the kind of nonsensical situation sweeping generalisations
> lead to.
I'm quite convinced that even if you view the Java virtual machine as
"bare metal", there are some startup bytecodes which are hand-written
rather than compiled from some Java source.
>> Logo though is THE toy language of all, as it's so focused on writing
>> cute animations quickly.
>
> Indeed, the simple syntax and graphics facilities have actually led
> people to do productive molecular modeling work in Logo. It's a shame
> that it's only a toy language or the research could have taken much
> longer for the exact same results.
Can you point to some published papers where a significant part
of the computer models were programmed in Logo?
>> The others are a mixture of application languages and scripting
>> languages. Of course they have their uses, but they will get in
>> your way if you want to program on the bare metal. True, many
>> programmers need never do that, OTOH Real Programmers enjoy doing
>> just that - that's why they need Real Programming Languages.
--
================================================================
Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
e-mail: pausch at saaf dot se or paul.schlyter at ausys dot se
WWW: http://hotel04.ausys.se/pausch http://welcome.to/pausch
------------------------------
From: [EMAIL PROTECTED] (Paul Schlyter)
Subject: Re: Visual Basic Source Code
Date: 18 Dec 2000 01:15:38 +0100
In article <3a3d0b6b$0$90275$[EMAIL PROTECTED]>,
Jason Bock <[EMAIL PROTECTED]> wrote:
> Sigh...can't seem to leave this alone.
>
> Paul Schlyter <[EMAIL PROTECTED]> wrote in message
> news:91i7t7$evc$[EMAIL PROTECTED]...
>> In article <3a3b9fe8$0$90278$[EMAIL PROTECTED]>,
>> Jason Bock <[EMAIL PROTECTED]> wrote:
>>> It's not ignorance. I know full well that VB is controlled by MS. But
>>> that doesn't bother me for the tasks at hand.
>>
>> Why are you so uninterested in having your code somewhat more
>> portable? Do you know in advance that your code will be so ephemeral
>> that porting it will never become an issue?
>
> I never said I wasn't uninterested. Stop putting words into my
> mouth - you said you didn't like that either.
No you didn't say it explicitly -- but you said you knew about it and
that it didn't bother you. Conclusions from that?
> There are situations where it's needed, and other times it's not.
> That's the way I've seen it.
There are situations where you THINK it's not needed -- but you don't
really KNOW after some years have passed. I've been porting some code
myself which obviously weren't written with porting in mind.
> There are more pressures in software development that programming
> in a "real programming language."
Indeed very true -- the pressure to get the software out quickly and
as cheaply as possible often make developers overlook these issues.
As a result the overall cost over the entire lifetime of the software
may go up -- but that doesn't bother the initial project which got
the first version of the software out the door, since that phase
probably got somewhat cheaper.
>>> That's not what I was trying to say. What I meant by "personal
>>> taste" is that, given a certain situation, it simply doesn't
>>> matter that something is portable.
>>
>> Very true -- sometimes it does not matter. For instance when:
>>
>> 1. your programming project is a failure -- no-one would be
>> interested in porting such code.
>>
>> 2. your code will have a lifetime so short that you'll know it'll be
>> obsolete when a different OS or environment becomes popular.
>
> Or, the project is a prototype,
Even if the project is a prototype, its code may be useful later in
the real implementation -- that is, if it is of good enough quality
to be resued at all... If it never makes it into a real
implementation, it becomes my case 1. above...
> or the project doesn't have the lifetime of years on end,
That was my case 2. above....
> etc., etc. Some projects don't live 20 years - sorry if you haven't
> seen this.
I've seen it all too much. I've seen projects which have lived less
than 1 year -- nevertheless even the code from such projects could
be reused in other, more long-lived, projects, if it's of good enough
quality.
>>> Sigh. OSes come and go, and I'll make the change. Of course, if we
>>> all wrote code in standard ANSI C++, the world would be perfect,
>>> right? Ain't going to happen, ever. Tools will come and go. OSes
>>> will come and go. Languages will come and go. If we could all just
>>> use one OS and one language, this wouldn't be an issue. But that's
>>> never going to happen. The key in my mind is that the communication
>>> between n systems is the same. Because this industry changes so much,
>>> that's about the best you can do.
>>
>> Perhaps that's a strategy to make sure you'll get jobs in the future:
>> make sure your applications are short-lived and need to be rewritten
>> from scratch once every few years..... <g>
>
> You can think that. Change happens irregardless of what I want to do
> or not. I don't pretend to have such control over the industry as a
> whole.
Neither do I -- thus we both agree changes will happen. Now, since
one knows changes will happen, why not try to plan for it a little?
Of course we won't know exactly what the changes will be,
nevertheless there are some things one can do. For instance try to
write portable code as much as possible, since portable code is more
likely to survive the next paradigm shift than non-portable code.
I think the only difference between us here is that you're
advocating short-term planning while I am advocating somewhat
more long-term planning, which initially may be somewhat more
expensive but which will pay itself back in the long run.
>> Now imagine if these principles were applied to other industries:
>>
>> a) you could only live in your house only for a few years, because
>> after that it would break down and would need to be rebuilt. No,
>> there's nothing you can do about that, that's just the way it is.
>> No builders want to build more endurable buildings, because if
>> they did, there would be too few jobs for them in the future.
>>
>> b) all your electrical appliances would need to be replaced every
>> few years or so. Today they run on 100 Volts, but next year
>> there's be an upgrade to 220 Volts, and a few years later to
>> 400 Volts. In between there'll be switches between 50 c/s,
>> 60 c/s, 100 c/s and DC !!!
>>
>> c) The new Car-2000 you bought yesterday cannot be driven because
>> it's incompatible with today's highway's -- you'll need to wait until
>> the Highway-2000 system has been opened -- unfortunately it's late
>> but it'll open "real soon now".... but that's OK really, because
>> then you'll have time to upgrade to Drivers-License-2000, since
>> your current driver's license won't authorize you to drive Car-2000....
>>
>> Just imagine.....
>
> Yep. Happens all the time in this industry. Are you going to stop it?
It will only stop when customers refuse to pay for that kind of
software anymore. Few single individuals will be able to
significantly influence this - yet you can decide what goal you
want to strive towards. And even if you fail to influence the
industry as a whole, you might make your own working situation
somewhat more tolerable.
> Other industries are different. People buying a house won't tolerate having
> their house broken down in three years. The computing industry simply
> hasn't fought back enough to force stability. But then again, I don't see
> that happening for a long time. The industry allows you to change things at
> a very rapid rate, much faster than building a house.
>
> Of course, building software does have a lot of analogies to building a
> house. But I just don't see things slowing down for a while. I can either
> fight to stay on one OS using one language for the rest of my life,
If you do, you'll have to do it as a hobby towards the end of your
life, when the commercial lifetime of that OS has ended.
> or I can decide to watch where things are going and make career changes
> based on such observations.
"If house built hoses the way programmers build software systems,
the next woodpecker which came along would destroy civilisation...."
--
================================================================
Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
e-mail: pausch at saaf dot se or paul.schlyter at ausys dot se
WWW: http://hotel04.ausys.se/pausch http://welcome.to/pausch
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: Use of multiplexing
Date: Mon, 18 Dec 2000 01:44:27 GMT
Mok-Kong Shen wrote:
>
> Multiplexing is a rather old topic in CS. In the crypto
> context, it is also well-known (see spread spectrum, CDMA).
> I like to consider the issue presently, however, purely
> at the application level, i.e. whether a normal user, who
> does encryptions as usual, can profitably apply multiplxing
> techniques of his own.
>
> In plenty of situations one does not send occassionally
> single messages. Between two distant officies of a
> commercial firm, for example, a substantial amount of
> communications, usually of different security levels,
> occur. It is thus feasible to multiplex the messages,
> i.e. intermingling them in some secret (either fixed or
> dynamically varying) way that is unknown to the opponent,
> thus rendering his analysis job difficult. There will
> certainly be some appreciable cost/work involved for
> the partners doing multiplexing, but the resulting
> difficulty caused to the opponent could under circumstances
> justify that, I believe. I wonder thus whether such
> multiplexing has not already been successfully employed in
> practice.
>
> We note that multiplexing can be done at two different
> levels, (intermingling of plaintexts and of ciphertexts),
> and also at different granularity (word/byte/bit).
>
> M. K. Shen
> -----------------------------
> http://home.t-online.de/home/mok-kong.shen
Indeed. One way that I've thought of for mutiplexing N messages on the
bit level, is to first create N arithmetic coder contexts, all outputing
to a single bitstream. Cycle though the N messages, taking one byte
from each, and output though the corresponding encoder. If these
messages have each undergone all but the last step of BWT compression
before being multiplexed, the compression is even better!
Also, unlike most encryption schemes proposed for using compression,
this one has an important advantage: the total size of the combined
message (output from the N arithmetic encoders) is exactly equal to the
total size of each one compressed seperately.
--
There are three methods for writing code in which no bug can be found:
1) Make the code so straightforward that there are obviously no bugs.
2) Make the code so complicated that there are no obvious bugs.
3) Insist that any apparent bugs were really intentional features.
------------------------------
From: "madcow" <[EMAIL PROTECTED]>
Subject: Re: Encryptian of data over radio transmission
Date: Sun, 17 Dec 2000 20:46:55 -0500
Assuming that this is legal where you are . . . ?
If you want decent results, you can get chips from mx-com:
http://www.mxcom.com/
or Motorola:
http://www.motorola.com/
Or you can get ready to solder in modules from
Selectone ( Communications Specialists Inc ):
http://www.selectone.com/
or
http://www.com-spec.com/
If you want to ham n egg it, you can try building a simple circuit with four
diodes, two transformers, and an audio oscillator, or other suitable sound
generator. Try looking in old copies of "Popular Electronics" magazine at
the library for the schematic. It's basically just a ring modulator, like
they use for SSB.
By the way, most two-way radio service companies will gladly add encryption
to commercial radios for a fee.
In any case, if you are modifying the radio itself, you will have to have
the unit tested to be sure it's not causing interference - very important !
Assuming that this is legal where you are . . .
Jordan McCallum <[EMAIL PROTECTED]> wrote in message
news:Bfo_5.159595$[EMAIL PROTECTED]...
> How can i encrypt voice data over FM. Schematics would be appreciated.
> Basically looking for a addon for a FM transciever i have. Also
schematics
> for the decryptor
>
> thanks
> jordan
>
>
>
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: Array shuffling
Date: Mon, 18 Dec 2000 01:58:35 GMT
Tim Tyler wrote:
>
> David Schwartz <[EMAIL PROTECTED]> wrote:
> : Matt Timmermans wrote:
>
> :> It would be incorrect if I had actually said that. What I said was
> :> the the lowest N bits of the state have a period at most 2^N, which
> :> is true.
>
> : You are literally correct. However, it's far from obvious that
> : this is necessarily a defect in the algorithm.
>
> This is also a description of the LCG in Sun's JVM.
>
> It uses a 48-bit state and outputs the top 32 bits.
>
> The defect is quite visible in simple programs - e.g.:
>
> http://alife.co.uk/nonrandom/
Although it's quite clear from your example that java.util.Random (and
rand() as well) are both nonrandom, there is no indication that rand()
is bad for practical use.
Certainly if we look at 2^16 calls to it at a time, we can easily see
the nonrandomness of the bottom bit, we aren't going to be, in most
situations, using ONLY the bottom bit.
If I convert the output of rand() into a float in the range [0,1), by
dividing by (float)(1<<16), the values will have quite decent
statistics.
--
There are three methods for writing code in which no bug can be found:
1) Make the code so straightforward that there are obviously no bugs.
2) Make the code so complicated that there are no obvious bugs.
3) Insist that any apparent bugs were really intentional features.
------------------------------
** 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
******************************
