Cryptography-Digest Digest #746, Volume #9 Tue, 22 Jun 99 05:13:03 EDT
Contents:
Re: Twinkle implementation? (David A Molnar)
Re: Sexual Contact Privacy (David A Molnar)
Re: Why Elliptic Curve Cryptosystem is stronger with shorter key length? (DJohn37050)
Re: Public key crypto (David A Molnar)
Re: CAST-256 implementation (?) (Uri Blumenthal)
Question related to letter frequencies... (Mike Keith)
Re: OTP is it really ugly to use or not? ([EMAIL PROTECTED])
Re: encrypt using ASCII 33 to 126 only? (wtshaw)
Re: Polyalphabetic Keyword Alphabets (wtshaw)
Re: Converting arbitrary bit sequences into plain English texts (wtshaw)
Just a small question (Sylvie Estrada)
Re: 8Bit encryption code. Just try and break it. - code3.ecr (0/1) (PhantomCoder)
Re: OTP is it really ugly to use or not? (Dave Hazelwood)
Re: Question related to letter frequencies... ("Douglas A. Gwyn")
Visit the Data Encryption Page (Anuj Seth)
Re: Caotic function ("Douglas A. Gwyn")
Secure broadcast ("Gene Sokolov")
----------------------------------------------------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: Twinkle implementation?
Date: 21 Jun 1999 23:45:59 GMT
Harvey Taylor <[EMAIL PROTECTED]> wrote:
> Hi Folks,
> So has there been enough info released for someone to actually
> build one of Shamir's TWINKLE devices?
Yes and no. The idea is described in some detail in Shamir's paper.
He pays attention to some of the issues which stand in the way of
building such a thing, like "how do I get all these factoring cells
on this GaAs wafer to synchronize ?!"
At the same time, there is a significant gap between a paper and
a set of explicit designs which would allow someone to build it
using only parts from Radio Shack. As far as I know, that gap has
not been bridged yet. At least in public.
The paper is at http://www.jya.com/twinkle.eps
So it seems to be in the category of "someone could build it, with
a lot of effort."
> Has anybody (that wants to talk about it)?
> <curious>
I don't know of anyone -- but I'd also love to hear of any efforts. :-)
-David
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: Sexual Contact Privacy
Date: 22 Jun 1999 00:18:55 GMT
Michael J. Fromberger <[EMAIL PROTECTED]> wrote:
>>> With all due respect, I think this is the biggest load of hoo-ha since
>>> the advent of deconstructionism. What possible "public good" could be
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>Hey, be careful with _that_ rhetoric, too.
> *grin* I wondered if anyone was going to nibble at that...
Hey, some of my best friends are literature concentrators... :>
>>Even so, it is a good thing to let newly at-risk partners know that
>>they're at risk.
> Yes -- on the other hand, I would argue that is the responsibility of
> the people in question, not the State. I feel this is a personal
> matter which does not impinge upon the _public_ good, and should
> therefore not be even considered for administration by central
> authority.
Oh, OK - I'm sorry, I was thinking of a looser notion of "public"
which encompasses "anything of interest to most people."
>>"is there a way to get the benefits we want - notification of newly
>>infected or at-risk ppl with STDs, establishment of paternity -
>>WITHOUT needing a centralized system which is prone to abuse?"
> I would argue that these are all individual problems, by which I mean,
> problems which should be handled between the partners and possibly
> their individual medical professionals. In particular, NOT handled by
> the State or any agency reporting to the State.
Oh, I agree. The point of reframing the question like that was
to see if it's possible to create a system which does not need
a centralized database, and hence has no reason to be administered
by the State.
Ideally (in the crypto-anarchist millenium), such a system would be
voluntary and work with consenting individuals. Maybe we could us
ideas from digital cash - particularly anonymous group membership
or maybe multiparty computation. Of course, one would also need
totally rational and 100% compliant members. :-\
>>>>
>>>> Allow universal determination of paternity?
>>>>
>>> Why should this matter?
>>
>>It matters a fair bit to some people, especially with respect to
>>child support laws.
> That's fine -- as far as I am concerned, such questions should be
> answered on an individual basis. Perhaps, as you suggest, DNA testing
> would be sufficient for this. But I would argue (and I think you'd
> agree) that this purpose in no way justifies a massive data bank of
> that sort.
Especially since it is not at all clear to me that a massive data
bank of sexual contacts is sufficient to establish paternity. Even
leaving aside questions of completeness, what happens when a woman
has more than one partner while fertile ? (and what do I do for
penance after writing that sentence?)i
Again, if there is any hope in this question, I think it's in
1) trying to isolate why anyone would want anything like this
and then
2) attempting to design cryptographic mechanisms which can be
used by private individuals w/o needing State intervention or
a centralized database.
-David
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: Why Elliptic Curve Cryptosystem is stronger with shorter key length?
Date: 22 Jun 1999 01:22:38 GMT
check out www.certicom.com, look at ECDSA white paper, for example.
The basic idea is that the hard math problem that ECC is based on appears
harder than the hard math problem that RSA is based on. There are no known
subexponential-time algorithms to solve a suitable elliptic curve problem. The
best are variants of Pollard rho algorithm, which is a square root algorithm.
There are subexponential time algs (GNFS) to solve the IFP, on which RSA is
based.
Don Johnson
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: Public key crypto
Date: 22 Jun 1999 00:52:23 GMT
Jerry <[EMAIL PROTECTED]> wrote:
> I am looking for a public key algorithm that is unpatented so that I can
> implement it for commercial use. Can anyone help me out here with some good
> sources to work from?
You may want to check out the almost-ratified IEEE P1363 standard.
http://grouper.ieee.org/groups/1363/index.html
It looks like you'll need to obtain a password, but the standard
is written with implementors in mind. While you're at it, you
will also want to subscribe to the announce lists to get news
about the standard.
You may be particularly interested in the DHAES paper - it
discusses how to "safely" implement ElGamal.
http://grouper.ieee.org/groups/1363/addendum.html
(note that this is part of the addendum to the standard)
Implementations : there's Wei Dai's Crypto++ at the P1363 site,
also OpenSSL at http://www.openssl.org
and you may want to check out the Number Theory Library while you're
at it (http://www.shoup.net/ntl/)
Just a final note -- do not implement ElGamal "naively", because
you may run into problems. For example, naive ElGamal signatures
are vulnerable to existential forgery. Here naive means that
you simply encrypt data directly with ElGamal (or whatever)
instead of somehow packaging/hashing/massaging the data first.
-David Molnar
------------------------------
From: Uri Blumenthal <[EMAIL PROTECTED]>
Subject: Re: CAST-256 implementation (?)
Date: Mon, 21 Jun 1999 21:38:25 -0400
Reply-To: [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
> It's not speed it's rounds. I wouldn't mind a slow eight round
> cipher. Because I would know that the transformation was secure and
> not just complex.
I wouldn't trust 8 rounds of any [block] cipher.
> For example TEA is very insecure at 8 rounds, but at
> 64 rounds (the suggested number) it's secure. That does
> not inspire a sense of confidence.
Au contrarie.
"Rounds are your friends".
--
Regards,
Uri
-=-=-==-=-=-
<Disclaimer>
------------------------------
From: [EMAIL PROTECTED] (Mike Keith)
Subject: Question related to letter frequencies...
Date: 22 Jun 1999 02:22:22 GMT
This is probably a simple question, but I'm not an expert in this area.
The question relates to a problem I'm working on, so any answers
or pointers to answers would be most appreciated.
It's easy to find a table of letter frequencies for, say, English text.
What this is really giving is, for each of the 26 letters,
the mean value of the probability density function for that letter.
What I want to know is...what is the actual pdf? Presumably
(but I'm just guessing) each of them is Gaussian (or close enough
that that's a good approximation) with some mean and variance.
Questions:
1) Is this true?
2) What are the variances?
If Gaussian is the right model I can measure #2 myself, but I wanted to
see if I was on the right track. Like I said, I can find the mean values
easily but none of the sources I've looked in treat the letters as PDFs
or talk about the variances.
Thanks.
Mike Keith
Web site: http://users.aol.com/s6sj7gt/mikehome.htm
(remove post-w letters from e-mail address)
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: OTP is it really ugly to use or not?
Date: Tue, 22 Jun 1999 01:28:14 GMT
RandAlthor wrote:
> FO wrote in message
> > About right software, having all that key material laying around -
> > perhaps it would be proper to protect the one time pad by encrypting
> > it in some way. But then it would be no safer than the encrypting =
> method.
>
> No, because the plaintext (the OTP) would be random, and so one could
=
> not ascertain if the correct OTP had been decrypted correctly- at
least =
> not until it was used to decrypt the original information (Potp). This
=
> means that to decrypt anything useful, the processing requirement will
=
> be additional to that under a standard OTP scheme, making this a good
=
> method.
FO is right. The processing requirment is negligible.
The provable security of the OTP is lost if the
adversary obtains the pad encrypted with some
non-perfectly secure cipher.
--Bryan
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: encrypt using ASCII 33 to 126 only?
Date: Mon, 21 Jun 1999 22:47:44 -0600
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Padgett 0sirius) wrote:
> >The problem with UUencode is that the output is perhaps too limited in
> >range, and therefore less efficient than it could be. OTOH, marginal
> >improvements in bandwidth efficiency are all that are available.
>
> You are not limited to uuencode and there are reasons (mainly E-Mail
> translators and IBM EBCDIC conversions) why the range is so small. These
> environmental limitations are often missed by developers with predictable
> results.
Obviously, there are restrictions that are going to be inobvious.
>
> Incidently it is entirely possible to create executable Intel programs using
> only the ASCII character set though you need to be careful to flush the
> cache before executing self-modifying code.
>
Surely this is a legacy fault. Filters should be in place to protect
against this sort of thing from routinely happening, but I doubt that
sufficient effort will be done for such a fix; it would mean actually
solving something rather than running in circles, looking busy, and
demanding payment for expertise.
--
Mirror, mirror on the wall: Where do you get your information?
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Polyalphabetic Keyword Alphabets
Date: Mon, 21 Jun 1999 22:53:13 -0600
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (John Savard) wrote:
> [EMAIL PROTECTED] (Rebus777) wrote, in part:
>
> >Please comment if you have something to add.
>
> Well, for one thing, instead of just showing how to make an alphabet
> from a keyword this way:
>
> COLUMBIADEFGHJKNPQRSTVWXYZ
>
> which inevitably leads to a weak alphabet, why not recommend the better method
>
......
>
> which is considerably more scrambled?
>
Aside from the fact that it may matter greatly how a key isused to judge
the scrambling results, a weaker key is apt to be more easily found, which
is an acknowledged help to those who like to actually solve
cryptosystems. If your orientation is to actually discourage this type of
activity, then your key generation procedures are apt to be more complex.
--
Mirror, mirror on the wall: Where do you get your information?
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Converting arbitrary bit sequences into plain English texts
Date: Mon, 21 Jun 1999 23:02:59 -0600
In article <[EMAIL PROTECTED]>, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:
> .....we can more generally demostrate that not only arbitrary
> program codes in ASCII but any bit sequences, in particular also
> executable files of crypto programs (which should be more severely
> subjected to export regulations) can be turned into plain English
> texts. .....
>
> Would the above fact be of interest to the court, should the Bernstein
> case be continued?
>
One way to look on this whole thing is that all information is always
convertable to another form, perhaps inefficiently so. Where there is a
will, there is a way..simple; where there is a loophole, it will be used
if needed.
Quickly we get to the question of whether government has a right to
control information, to censor as it pleases; this is the root matter
regardless of all the stagecraft going on to hide the bottom line that the
Constitution is meant to protect the people from arbitrary abuse.
--
Mirror, mirror on the wall: Where do you get your information?
------------------------------
Date: Tue, 22 Jun 1999 00:56:55 -0400
From: Sylvie Estrada <[EMAIL PROTECTED]>
Subject: Just a small question
can anyone suggest a begginers book about cryptology? I am an engineer,
and good with math. I just became interested in the topic, but I need
the very basics.
Thanks
------------------------------
From: [EMAIL PROTECTED] (PhantomCoder)
Subject: Re: 8Bit encryption code. Just try and break it. - code3.ecr (0/1)
Date: Tue, 22 Jun 1999 06:10:52 GMT
The ciphertext that I looked at via IRC was very interesting and demonstrated
that the algorithm has some serious flaws... I base this simply on the
frequency that each byte value occurs... I am not an expert, but even I know
that without the source code, it is virtually impossible to analyze the
algorithm thoroughly.
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Phoenix)
wrote:
>On Fri, 28 May 1999 20:55:05 -0700, Phoenix <[EMAIL PROTECTED]> wrote:
>Here is a better message with a better code. NO I will not publicize
>my algorythm (my co-programmer forbids it) when it is broken by one of
>you I will send it to someone (CoderX2, anyone else who wants it) and
>have it evaluated. But I would still like people to try and break it.
>Also its not 8-bit it is 16. And I know that uncertainty about the
>algorythm would add more bits. So here it is.
>
> [EMAIL PROTECTED]
>
>
------------------------------
From: [EMAIL PROTECTED] (Dave Hazelwood)
Subject: Re: OTP is it really ugly to use or not?
Date: Tue, 22 Jun 1999 06:17:29 GMT
[EMAIL PROTECTED] (Mickey McInnis) wrote:
>What I'm suggesting is this:
<snip>
>
>B) If you've used a PRNG to generate your pad, they can, in theory,
>tell whether the pad that matches your innocuous cleartext to the
>ciphertext could have come from your PRNG. Given a
>cleartext/ciphertext pair and a PRNG algorithm you will probably
>not be able to produce a PRNG seed that will produce a matching
>pad.
>
>The practicality of "B" depends on PRNG algorithm, bit length of
>the seed, "randomness" of the seed, whether they expect you to
>remember the seed, processing power available, etc. but it is a
>theoretical risk.
Yeah but it is a bit far out. I think it would be more suspect if
you did remember the seed! I mean nobody remembers that stuff
except maybe cryptographers <g>. A normal person sure would not.
I would just play like Liberace on the keyboard to seed a proggie
to generate the pad and would not even know or care what I
entered. A proggie where you just wiggle the mouse and tap on the
enter key and it uses that to seed the generator so there is nothing
to remember right?
>
>The simplest example of "B" is that that demand you produce the
>seed you used to initialize your PRNG. They may not believe you
>if you tell them you don't remember.
They have to. They can't prove otherwise. First of all it is not
important to remember it. I mean it's not like a "key" to a block
cipher or anything so there is no reason to remember it. You can make
this case. You could also make the point that you purposely never take
note of the seed so you can never compromise your own security as a
matter of policy. What can they say to that? Nada.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Question related to letter frequencies...
Date: Tue, 22 Jun 1999 06:56:40 GMT
Mike Keith wrote:
> It's easy to find a table of letter frequencies for, say, English
> text. What this is really giving is, for each of the 26 letters,
> the mean value of the probability density function for that letter.
No. It is an *estimate* of the probabilities of occurrence of each
letter at a given position in English plaintext *with all context
disregarded*. In reality, if (for example) you know that a Q has
just occurred, the likelihood of U being next is very high. And
there are higher-order correlations. In fact, at the trigraph level
the distribution is vastly farther from uniformly flat than is the
case for the individual letter frequencies.
> What I want to know is...what is the actual pdf? Presumably
> (but I'm just guessing) each of them is Gaussian (or close enough
> that that's a good approximation) with some mean and variance.
> 1) Is this true?
No, you're working from the wrong premises here.
Too bad you didn't tell us what your application was, or we might be
able to steer you in the right direction. If it's something like
speech recognition, Jelinek's book will get you started.
------------------------------
From: Anuj Seth <[EMAIL PROTECTED]>
Subject: Visit the Data Encryption Page
Date: Mon, 21 Jun 1999 23:29:13 -0800
Hi,
Visit "The Data Encryption Page" at
http://visitweb.com/crypto
OR
http://www.geocities.com/SiliconValley/Network/2811/
D.E.P. has lots of cool links, source code, and
documentation/tutorials on cryptography to keep you busy for
days! ;-)
Don't forget to sign the guestbook.....
With Regards,
Anuj
**** Posted from RemarQ - http://www.remarq.com - Discussions Start Here (tm) ****
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Caotic function
Date: Tue, 22 Jun 1999 06:38:22 GMT
"John E. Kuslich" wrote:
> My criticism was intended for the individual who originally made the point
> that complex numbers and chaos and fractals (and even cryptography) are
> not related...
I disputed the claim that chaos depended on complex numbers.
There are, of course, uses of complex numbers throughout analysis,
including being the simplest way to express the famous Mandelbrot
function whose divergence map you've all seen on calendars, etc.
But chaos depends only on the nature of dynamical systems, not on
whether or not complex numbers are somehow used in their description.
In fact there are chaotic 1-dimensional systems, for which clearly
a complex-number model would be inappropriate.
------------------------------
From: "Gene Sokolov" <[EMAIL PROTECTED]>
Subject: Secure broadcast
Date: Tue, 22 Jun 1999 10:41:59 +0400
I have a task of setting up a system to broadcast real time data to the
clients:
I. Description:
1. The data is sold on subscription basis at about US$500/month. A
20-minutes delay would cut the value of the data 10 fold. A 2 hour delay
would make this data nearly worthless.
2. The data is sent through one-way medium (pager), one server -> multiple
clients. The same data stream is sent to all clients. Clients cannot send
anything back to the server.
3. All clients obtain individual user id/password combination once (for
example when they sign the contract). Password is about 52 bit long
(36**10). We assume that our way of distibuting passwords is secure. We also
assume the password distribution procedure to be difficult/expensive to
repeat often.
II. Goal:
1. The data stream should be encrypted in such a way, that brute-force
decryption is too expensive (I.1).
2. There should be a way to add/remove clients easily. We don't want to
distribute new passwords every time a client is dropped.
Is there a known scheme for such broadcast? Any pointers where information
can be obtained?
Thanks.
Gene Sokolov
hook(at)aktrad(dot)ru
------------------------------
** 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
******************************
