Cryptography-Digest Digest #311, Volume #13 Mon, 11 Dec 00 23:13:00 EST
Contents:
Sr. Cryptographer/mathematician ("Kevin")
Re: ElGamal questions (Tom St Denis)
Re: Array shuffling (lcs Mixmaster Remailer)
Re: Array shuffling (Benjamin Goldberg)
Re: binary vs. text w/ regard to digital signatures (Benjamin Goldberg)
postdoctoral positions at Waterloo (Alfred John Menezes)
Re: Unguessable sequence of unique integers? (Bob Silverman)
Re: A challenge ("Michael")
Re: important programming languages (Bob Silverman)
Re: important programming languages (Bob Silverman)
Re: Array shuffling ("Matt Timmermans")
Re: How to embed a key in executable code? ("Brian McKeever")
Re: Array shuffling (David Schwartz)
Re: Array shuffling (Benjamin Goldberg)
Re: How to embed a key in executable code? ("Matt Timmermans")
Re: Bilderbergs --- see also who are there from Finland ... these are (Chris
Ahlstrom)
----------------------------------------------------------------------------
From: "Kevin" <[EMAIL PROTECTED]>
Subject: Sr. Cryptographer/mathematician
Date: Mon, 11 Dec 2000 21:05:52 -0500
WE ARE LOOKING FOR EXPERT CRYPTOLOGISTS
in Ottawa, Canada
You will have experience in 1 or more of these
- Ciphers
- Cryptographic protocols
- Crytpographic hashing methods
- Computaional complexity theory
- Combinatorics
- Number theory
- Numerical analysis
As part of the technology team you will participate in the design and
analysis of our technology with regards to mathematical and/or cryptographic
techniques. You will aslo be expected to design new applications in the
above areas for incorporation into our secret-hiding, tamper proof software
encoding tools and to program key components to incorporate the designs into
our tool set.
Knowledge of Java, c++ Eiffel,Modula-3 or other object oriented language is
essential.
If you're the person
contact
Kevin Ireland
[EMAIL PROTECTED]
[EMAIL PROTECTED]
613-786-3106 ext 231
613-799-4310 cell
613-489-4299 home
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: ElGamal questions
Date: Tue, 12 Dec 2000 02:09:51 GMT
In article <913mg4$4o0$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> Hi, I'm new on security so correct me if I'm wrong.
>
> In public key algorithms like ElGamal the message to
> be encrypted is actually encrypted using a simetric
> algorithm. And the key of the Simetric is encrypted
> using the public key.
>
> I need to encrypt messages no longer than 128 bits
> and the performance is very important.
>
> So I was thinking on taking the simetric algorithm and
> use "pure" Elgamal to encrypt my data, I mean using the
> algorithm used to encrypt the simetric key to encrypt my data.
>
> Someone knows if this is "secure" and where to get a simple
> implementation (C/C++) of this algorithm that I can modified
> to achieve this?.
>
> Thanks in advance.
If you are truly performance driven you will not use ElGamal. Instead
develop a key negotiation scheme using a one-time generated shared DH
key and use "symmetric" encryption for all further communications.
I did this in my old Peekboov2 program. Two people would make a shared
DH key and I would hash the shared-secret (big 2048-bit number) plus a
random IV (I appended to the message) to make a session key to encrypt
the message. Once you make the shared secret sending messages only
required to hash some text and encrypt via a fast symmetric cipher.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: 12 Dec 2000 02:20:02 -0000
From: lcs Mixmaster Remailer <[EMAIL PROTECTED]>
Subject: Re: Array shuffling
Benjamin Goldberg writes,
> I took it upon myself to
> write my own array shuffler, which uses random bits in the most
> efficient way possible.
Interesting problem. A couple of points:
The proof of unbiasedness is easy, by induction.
The "i" loop divides the input into two parts, of size lt and rt (such
that lt + rt = len, the number of elements). Each element is randomly
assigned to one of the two parts, hence each element has a chance of
lt/len of being in the first part and rt/len of being in the second part.
We now recurse and (by induction) get an unbiased permutation of each of
the two parts. This means that the chance of a given element ending up
in a given position of the lt part is 1/lt. We multiply by the lt/len
chance of being in that part, giving the desired 1/len chance of being
at a given position, and likewise for the rt part. QED.
Note that the do/while loop is technically not needed, as you can get the
same effect by recursing. However doing it your way limits recursion
depth to at most len. Another way to structure the code would be to
use tail recursion (where one of the recursive calls is substituted by
a loop). As it is you have a loop plus two recursive calls, which is
a bit redundant.
The question arose as to how to do an efficient modran, a function
which returns a random value from 0 to n-1, for arbitrary n. One way
to think of such a function is as a filter on a stream of random bits.
Such a function needs to be stateful in order to be efficient and not
waste randomness.
The desired function comes from the theory of arithmetic compression.
Arithmetic compression takes data with a known probability distribution
and compresses it into a perfectly random binary bit string (assuming
the data matches the expected distribution). The reverse function is
what is needed for modran. It takes a random binary bit string and
returns values with any required probability distribution, including
the 1/n case required for modran.
Use an arithmetic decompression function, and feed it with your random
bit source. Request data with a 1/n probability distribution on an
as needed basis, varying n appropriately. The arithmetic decompressor
will retain state corresponding to fractional bits, and will use new
bits only when needed. It should provide optimal results.
See the comp.compression FAQ for information and sample code implementing
arithmetic compression and decompression.
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: Array shuffling
Date: Tue, 12 Dec 2000 02:31:12 GMT
Mok-Kong Shen wrote:
>
> Benjamin Goldberg wrote:
> [snip]
>
> > I submit it here for your review and comment on. Although this
> > algorithm also takes a nondeterministic amount of time to complete,
> > it should use N*log(N) bits on average, and the nondeterministic
> > part is where you can see it, in the do/while loop, not hidden in
> > random number function. This shuffler should not be biased if
> > randbit() is not biased.
> [snip]
>
> I have a problem with your argument. There are 2^(N*log(N))
> different bit sequences of length N*log(N), while there
> are N! different permutations. N! ultimately exceeds by
> far 2^(N*log(N)).
Instead of comparing N! to 2**(N*log(N)), try comparing N*log(N) to
log(N!). log(N!) is equal to the sum, from i=1 to N, of log(i). For
example, log(5!) == log(5)+log(4)+log(3)+log(2)+log(1), which is much
less than 5*log(5). From this, we can see that 2**log(N!) does NOT
exceed 2**(N*log(N)), and in fact the opposite is true.
> Wouldn't if follow that, starting from
> a fixed array content and applying all bit sequences, there
> are certain permutaions that one can never get, i.e. the
> algorithm is generating only a subset of all permutations,
> if N is sufficiently large? BTW, doesn't your 'non-
> deterministic amount of time to complete' also point to the
> same direction? Thanks.
>
> M. K. Shen
Nondeterministic amount of time to complete means that we cannot
garuntee that the number of bits used will have any particular bound,
and that the amount of time used will not have any particular bound.
To quote Paul Crowley and Scott Fluhrer's reply to him:
> > However, it's biased. In fact, *any* shuffling method
> > which uses a bounded number of bits has to be biased.
> However, it is technically unbounded -- if all of the elements end up
> going to one partition, the algorithm tries again. For example, if
> you replace randbit() with something that always returns 0 (or always
> return 1), the algorithm will never terminate[1].
[Snip mistaken statement that the number of bits used is bounded]
> [1] Note: this is *not* a criticism of the algorithm -- as Paul
> mentioned, for N>=3, any unbiased shuffling algorithm based on random
> bits will never terminate on some sequence of random bits.
--
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: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: binary vs. text w/ regard to digital signatures
Date: Tue, 12 Dec 2000 02:31:24 GMT
denis bider wrote:
[snip]
> (3) Encoding of national characters.
>
> The same XML document may validly appear in any conceivable encoding;
> UTF-8, UTF-16, ISO-8859-2, EUC-JP, you name it. Most national
> characters will be encoded differently in one encoding than in
> another.
>
> Hence, if you want to compare two XML documents, you have to know the
> character encodings of BOTH documents.
>
> EDDF uses canonical UTF-8 for all character data. Such a UTF-8 string
> is equal to another UTF-8 string when the encodings are equal. No
> dilemma.
I have one minor nitpick here. Some characters, such as n with a ~ over
it, have two graphically identical encodings -- as a single [combined]
symbol, and as a letter (the n) followed by a non-spacing symbol (the
~). This applies to most of the letters of latin-1 which have the high
bit set; they have their own encodings, and they can be encoded as the
letter, followed by a non-spacing form of the overmark.
Of course, this is a problem with UTF, than with EDDF, but it is there,
and you shouldn't overlook it.
--
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: [EMAIL PROTECTED] (Alfred John Menezes)
Subject: postdoctoral positions at Waterloo
Date: 12 Dec 2000 02:14:49 GMT
====================================================================
Postdoctoral Positions in Cryptography And Quantum Computing
Centre for Applied Cryptographic Research
Department of Combinatorics and Optimization
University of Waterloo
Applications are invited for several one-year and two-year
postdoctoral positions in any area of cryptography or quantum
computing. Some of these positions are being funded through the
Applied Cryptography project, which is part of the MITACS Network of
Centres of Excellence.
A Ph.D. and proven ability, or the potential, for excellent research
is required. Responsibilities may include teaching one undergraduate
or graduate course per year. Successful candidates will be joining a
substantial research and training centre in cryptography at the
Centre for Applied Cryptographic Research (CACR). Information about
CACR personnel and activities can be found at
www.cacr.math.uwaterloo.ca
The normal starting date of appointment is July 1, 2001, however this
can be changed on the applicant's request. A $3,000/year travel grant
will be provided (with the possibility of more travel funds subject
to availability).
Interested individuals should send a Curriculum Vitae, 2 or 3
selected reprints/preprints, and the names of three references to:
Cryptography PDFs
Department of Combinatorics and Optimization
Faculty of Mathematics
University of Waterloo
Waterloo, Ontario, Canada N2L 3G1
Email: [EMAIL PROTECTED]
Phone: (519) 888-4566 x3482
Fax: (519) 725-5441
http://math.uwaterloo.ca/CandO_Dept/homepage.html
Closing date for receipt of applications is March 15, 2001. Some
applications may be processed as they are received.
====================================================================
------------------------------
From: Bob Silverman <[EMAIL PROTECTED]>
Subject: Re: Unguessable sequence of unique integers?
Date: Tue, 12 Dec 2000 02:28:17 GMT
In article <[EMAIL PROTECTED]>,
moc.qit@nahoj wrote:
> Hello.
>
> I am looking for an algorithm for a generator of a sequence
> of unique and unguessable 32-bit integers.
> The number of integers created by the sequence must be
> very large, i.e. in the 32-bit range and no two values
> in the sequence must overlap until a fairly large number
> (a minimum of 2^24 or so) of values have been found.
Impossible.
(1) If it is truly generated by an algorithm, as opposed to a
(say) true white noise generator, then the sequence can be guessed
or deduced.
(2) Any truly random or pseudo random 32-bit sequence will have,
with high probability a collision after 2^16 values. The probability
of a collision after 2^20 is near certainty. Look up the
birthday problem.
What you want does not exist.
--
Bob Silverman
"You can lead a horse's ass to knowledge, but you can't make him think"
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Michael" <[EMAIL PROTECTED]>
Subject: Re: A challenge
Date: Tue, 12 Dec 2000 02:59:57 GMT
Why didn't you post the decrypted message since you gave the spoiler
disclaimer?
Michael
"Jakob Jonsson" <[EMAIL PROTECTED]> wrote in message
news:9121pi$csf$[EMAIL PROTECTED]...
> Hi,
>
> For newsgroup readers: This text contains some (minor) spoilers, so please
> beware.
>
>
>
>
>
>
>
>
>
> I think this is a quite good exercise, at least if the students (or
whatever
> they are) have some cryptographic experience in advance (but don't expect
> them to break it within an hour unless they are particularly clever). I
have
> tried it myself, and I succeeded in extracting the plaintext. Yet, I
failed
> to determine the general rule for decryption. Decrypting a single word by
> checking all 26 possible rotations is easy (given that you know the rule),
> but it is hard to see how the rotation numbers are generated.
>
> By the way, there seem to be plenty of errors in the ciphertext:
>
> "panumfhhna" -> "panumfhhnz"
> "hhuqvxajf" -> "hhuqvxzjf"
> "tvuuxxnxl" -> "tvuuxsnxl"
> "uffc" -> "uftc"
> "maaaak" -> "maalak" (?)
> "libbr" -> "libkr"
> "qbb" -> "qbp" (etc ;) )
> "uaq" -> "uhq"
> etc.
>
> (Or I may have misinterpreted something...) Are those errors deliberate?
> They make the cryptanalysis a bit harder, but they certainly give the
cipher
> a flavor of authenticity.
>
> A suitable hint for students who get stuck: Tell them to guess the meaning
> of obk and ive and ask them to find the correct way of decrypting these
> words. They can check their hypotheses by decrypting obkrw and ivelq.
(This
> is the way I broke it.)
>
> Finally (this is clearly a spoiler):
>
> Where does the text come from? To me, it sounds like a Star
> Wars/Tolkien-inspired poem. When I tried to decrypt "Ftfjlkai", the only
> thing that was close to making sense was "Shinuawa". Is there some error
in
> "Ftfjlkai" or is Shinuawa the name of the kingdom in the poem?
>
> Jakob
>
> <[EMAIL PROTECTED]> skrev i meddelandet
> news:90mtvl$el6$[EMAIL PROTECTED]...
> > I'm developing a cypher for a game and would like the encoded message
> > to be breakable without extensive use of a computer. Since I know the
> > cypher I am hardly a good judge of how difficult it is to crack.
> > Therefore, I am putting out the challenge to any of you to break the
> > encoded text that follows.
> >
> > And no, this has nothing to do with school.
> >
> > Thanks!
> >
> > E panumfhhna fa obk sngei oqbo hhuqvxajf md lnwlx. N ekav hud ayhhm wm
> > ghcgxcdb paqnh wjcah xn pa lipa. O megu uffc uaq thrtpf. Ylu ocmoka
> > uk Ftfjlkai yaeawqj nh ome jrkk. Tgpm sie wm kaswq pkdbf zlo libbr
> > obkrw rrerfvdjfwpv, maaaak owq yii rl mxx, mgkk ive qbufaxl nd ivelq
> > zvrhpj.
> >
> > L paa quqshdcy prmpadth njog ncfwjrfy ums xkfsn rliofend hmaollh kxgns
> > dntplib. M qbb ivep lvhs. B mpeuq naju jwajtv wjsae abwwwfspeesl. W
> > itt eral lyclvx hludt lvigpfqjp. P bmm cpyfk jvmgp; c eqhbk wjoo fvvnr
> > bjqp.
> >
> > T hixlm yiqq wessydr ko d wkiojbbt zmvs doff rxrf xr dvsdpddjps, tn ubo
> > fsb nde nojrxkdhpvfxa nd Ftfjlkai gsv gmgu lyhe wycsrme im cpy
> > tufgefwxlhyr pf sudse.
> >
> > B hss najqv kwnhq tvuuxxnxl xxe...
> >
> >
> > Pendergarth
> >
> >
> > Sent via Deja.com http://www.deja.com/
> > Before you buy.
>
>
>
------------------------------
From: Bob Silverman <[EMAIL PROTECTED]>
Subject: Re: important programming languages
Date: Tue, 12 Dec 2000 02:48:16 GMT
In article <lqbZ5.12088$I5.128757@stones>,
"Brian Gladman" <[EMAIL PROTECTED]> wrote:
>
> "Bob Silverman" <[EMAIL PROTECTED]> wrote in message
> news:913eav$tgi$[EMAIL PROTECTED]...
> > In article <IaaZ5.12042$I5.127023@stones>,
> > "Brian Gladman" <[EMAIL PROTECTED]> wrote:
> > > So if you truly consider this to be no more than 'a minor nitpick'
> > you are
> > > illustrating your own lack of knowledge of the full breadth of
> > requirements
> > > for cryptographic algorithm implementation in the real world.
> >
> > ROTFL.
>
> You might consider ignorance a laughing matter but I do not.
What I was laughing about was the suggestion that I might be
ignorant about implementing crypto algorithms in the real world.
And yours is showing. I have implemented crypto software and
computational number theory software on more different platforms
and architectures than I can count;
I have written computational code on Z80's Z8000's
68000's , 68010, 68020, 80286, 80386, Pentium, PDP-11, VAX, DEC-10
IBM-370, Cray-1, RS6000, R3000, R10000, PA-RISC, Alpha's , DEC-20,
Burroughs 6700, I860, plus some parallel architectures which no longer
exist: Intel Hypercube, Thinking Machines CM2, CM5. I have written
such code in a multitude of assemblers, in Algol, in Fortran IV
and Fortran '77. In Bliss, In C, in C++, in Franz Lisp and Common
Lisp. etc. etc. And of course, under so many different OS's that
I don't remember all of them.....
I also have some engineering responsibilities for BSAFE.
The idea that I might be ignorant about what is needed to make
crypto code work across a variety of platforms is hilarious.
--
Bob Silverman
"You can lead a horse's ass to knowledge, but you can't make him think"
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Bob Silverman <[EMAIL PROTECTED]>
Subject: Re: important programming languages
Date: Tue, 12 Dec 2000 02:50:15 GMT
In article <913eav$tgi$[EMAIL PROTECTED]>,
Bob Silverman <[EMAIL PROTECTED]> wrote:
> In article <IaaZ5.12042$I5.127023@stones>,
> "Brian Gladman" <[EMAIL PROTECTED]> wrote:
> > So if you truly consider this to be no more than 'a minor nitpick'
> you are
> > illustrating your own lack of knowledge of the full breadth of
> requirements
> > for cryptographic algorithm implementation in the real world.
>
> ROTFL.
>
> --
> Bob Silverman
> "You can lead a horse's ass to knowledge, but you can't make him
think"
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
>
--
Bob Silverman
"You can lead a horse's ass to knowledge, but you can't make him think"
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Matt Timmermans" <[EMAIL PROTECTED]>
Subject: Re: Array shuffling
Date: Tue, 12 Dec 2000 03:29:17 GMT
"Benjamin Goldberg" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Curiously, testing seems to show that if 2**17 tests are made, the low
> bit of rand() is 0 exactly 2**16 times. If 2**18 tests are made, the
> second lowest bit is 0 exactly 2**17 times. This progression holds for
> the lowest 4 bits, but I don't have the patience to test if this holds
> for the rest of the bits.
Most rand() implementations that ship with compilers are not very good.
Here's the one in the compiler I use (clarified):
int rand()
{
static unsigned long seed;
seed=seed*_some_constant_;
seed+=_some_other_constant;
return((seed>>16)&32767);
}
The period is 2^31, but all of the operations on the state are additions and
multiplications mod 2^32, so the higher bits of the state never affect the
lower ones. The lowest N bits of the state must, therefore, have a period
of at most 2^N.
It looks like you and I use the same compiler -- the rand() functions
returns bits 16-30, bit 16 has a period of 2^17, bit 17 has a period of
2^18, etc.
------------------------------
From: "Brian McKeever" <[EMAIL PROTECTED]>
Subject: Re: How to embed a key in executable code?
Date: Mon, 11 Dec 2000 19:41:57 -0800
"Darren New" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>
> Basically, some folks here are asserting that it's impossible to make an
> algorithm so hard to understand that one cannot figure out if it ever gets
> to a certain statement or not. I would contend that the halting problem
> would seem to imply that's wrong. (Of course, AFAIK the halting problem
only
> applies to unbounded computers, etc, but still...) To say "it's
impossible"
> rather than "nobody knows how" or "it's extremely difficult" is a
> simplification, methinks.
Well, I'm not so sure it's as easy as that. Don't forget that a
(determined) cracker also
has the ability to edit the machine code... Changing a call to
CheckValidLicense() to a noop can be done.
Brian
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: Array shuffling
Date: Mon, 11 Dec 2000 19:40:41 -0800
Matt Timmermans wrote:
> int rand()
> {
> static unsigned long seed;
>
> seed=seed*_some_constant_;
This multiplication causes the lower bits to affect the higher bits.
> seed+=_some_other_constant;
> return((seed>>16)&32767);
The outputs based on the high bits.
> }
> The period is 2^31, but all of the operations on the state are additions and
> multiplications mod 2^32, so the higher bits of the state never affect the
> lower ones. The lowest N bits of the state must, therefore, have a period
> of at most 2^N.
The higher bits of the state don't affect the lower ones, but the lower
ones affect the higher ones, the higher ones affect the higher ones, and
the output comes from the higher ones. So your argument that the period
is at most 2^16 is incorrect. At least, assuming my head is clear, which
I think it is.
DS
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: Array shuffling
Date: Tue, 12 Dec 2000 03:46:38 GMT
lcs Mixmaster Remailer wrote:
>
> Benjamin Goldberg writes,
> > I took it upon myself to
> > write my own array shuffler, which uses random bits in the most
> > efficient way possible.
>
> Interesting problem. A couple of points:
>
> The proof of unbiasedness is easy, by induction.
[snip proof by induction]
Thanks! I'm putting this post in my files for reference :)
[snip tail recursion stuff]
I realize that one can change one of the two recusive calls to be a tail
recursion, but doing it this way is a bit easier to read.
> The question arose as to how to do an efficient modran, a function
> which returns a random value from 0 to n-1, for arbitrary n. One way
> to think of such a function is as a filter on a stream of random bits.
> Such a function needs to be stateful in order to be efficient and not
> waste randomness.
>
> The desired function comes from the theory of arithmetic compression.
> Arithmetic compression takes data with a known probability
> distribution and compresses it into a perfectly random binary bit
> string (assuming the data matches the expected distribution). The
> reverse function is what is needed for modran. It takes a random
> binary bit string and returns values with any required probability
> distribution, including the 1/n case required for modran.
>
> Use an arithmetic decompression function, and feed it with your random
> bit source. Request data with a 1/n probability distribution on an
> as needed basis, varying n appropriately. The arithmetic decompressor
> will retain state corresponding to fractional bits, and will use new
> bits only when needed. It should provide optimal results.
But how can I be certain that it's unbiased?
> See the comp.compression FAQ for information and sample code
> implementing arithmetic compression and decompression.
--
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: "Matt Timmermans" <[EMAIL PROTECTED]>
Subject: Re: How to embed a key in executable code?
Date: Tue, 12 Dec 2000 03:52:23 GMT
<[EMAIL PROTECTED]> wrote in message
news:913oaa$6a1$[EMAIL PROTECTED]...
> [...]
> Alice does not have to figure out every detail of
> what is being done, only enough to fake a correct response from the
> verification, this could be done through removing code from the
> program, adding code to the program, changing code, altering disk data,
> etc.
>[...]
You have not established that this part is feasible. "enough" could be a
lot. You have also ommitted the step of isolating the verification code
from application functionality, which is not necessarily feasible either.
To avoid confusion, however, I'll note that you started with:
> This situation is quite simply, that Alice and
> Bob are the same person, and Alice/Bob wants to reveal information
> about the communication. I don't care what protocol you use, how
> sophisticated it is, or even how much trouble is involved. There is no
> way to stop Alice/Bob from revealing the information.
This is correct, but it is not the same as your detailed case, because
revealing the information requires no reverse engineering, and because the
"information" in question includes personal information or verification code
that "Alice/Bob" does not want to reveal -- the program has to be cracked.
------------------------------
From: Chris Ahlstrom <[EMAIL PROTECTED]>
Crossposted-To: alt.security,comp.security
Subject: Re: Bilderbergs --- see also who are there from Finland ... these are
Date: Tue, 12 Dec 2000 03:53:27 GMT
"Markku J. Saarelainen" wrote:
>
> http://ourworld.compuserve.com/homepages/grattan_healy/Bild-az-tab.html
>
> Ahlström, Krister, President and CEO, Ahlström Group
Cool, almost the same spelling as my name! But you're message
means nothing to me. Can you explain it? Thanks!
Chris Ahlstrom
------------------------------
** 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
******************************
