Cryptography-Digest Digest #654, Volume #10 Tue, 30 Nov 99 17:13:01 EST
Contents:
Re: compact encryption in javascript ("Eike Kock")
Re: more about the random number generator (Jim Dunnett)
Re: Elliptic Curve Public-Key Cryptography (DJohn37050)
Re: compact encryption in javascript ("Eike Kock")
Re: Elliptic Curve Public-Key Cryptography (DJohn37050)
Re: Quantum Computers and PGP et al. (Greg)
Re: Quantum Computers and PGP et al. (Greg)
Re: VIC cipher strength? ("r.e.s.")
Re: AES cyphers leak information like sieves (Brian Chase)
Re: A dangerous question ("Douglas A. Gwyn")
ECC (Pascal Nourry)
Re: Paradise shills?? ("Douglas A. Gwyn")
Re: How safe is Mobile Phone ? (Patrik Norqvist)
Re: AES cyphers leak information like sieves (Derek Bell)
----------------------------------------------------------------------------
From: "Eike Kock" <[EMAIL PROTECTED]>
Subject: Re: compact encryption in javascript
Date: Tue, 30 Nov 1999 21:25:42 +0100
Thanx for the code. Is it *save*?
John Bailey <[EMAIL PROTECTED]> schrieb in im Newsbeitrag:
[EMAIL PROTECTED]
> On Mon, 29 Nov 1999 14:33:22 +0100, "Eike Kock" <[EMAIL PROTECTED]>
> wrote:
>
> >Hi!
> >
> >I am looking for a compact public-key-based encryption algorithm I can
> >easily implement using javascript in less than 10 lines of code. Anyone
know
> >of something like this.
> >
> >Thank you in advance,
> >Eike
> >
> >
> function ClearForm(form){ form.x.value = ""; form.y.value = "";
> form.mod.value = ""; form.result.value = "";
> }function computeform(form) { var r = 1, x, y, m ;
> x = parseInt(form.x.value) ;
> y = parseInt(form.y.value) ;
> m = parseInt(form.mod.value)
> while(y > 0) {
> r = (r*x % m)*(y % 2) + (1 - y % 2)*r ;
> x = x * x % m ;
> y = Math.floor(y/2) ;
> }
> form.result.value = r ;
> return;}
> Try it out at:
>
http://www.frontiernet.net/~jmb184/interests/cryptography/small_num_expont.h
tml
> John
------------------------------
From: amadeus @DELETE_THIS.netcomuk.co.uk (Jim Dunnett)
Subject: Re: more about the random number generator
Date: Tue, 30 Nov 1999 20:18:59 GMT
Reply-To: Jim Dunnett
On Tue, 30 Nov 1999 17:52:30 GMT, [EMAIL PROTECTED] (Brian Chase) wrote:
>In article <[EMAIL PROTECTED]>, Anton Stiglic <[EMAIL PROTECTED]> wrote:
>>Tom St Denis wrote:
>
>>> Optimum compression would reduce the size
>>> of this 417792 bit file by 0 percent.
>
>>This comes directly from the entropy result.
>
>Naive question here. Let's say you had access to some "optimum
>compressor" which would take arbitrary data sets distill them into their
>most compact form. By definition, the resulting data must have no
>predictable redundancies, yes? Could you use optimally compressed data
>sets as sources for random numbers?
How about getting two long compressed files, then XOR them to
the length of the shortest. Then test the result, you'll find it scores
well on what tests are available for 'randomness'.
Then again, the perfectionists would probably pick holes in this
method!
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: Elliptic Curve Public-Key Cryptography
Date: 30 Nov 1999 20:28:05 GMT
The strange word in my previous post was supposed to be "advantages" of ECC.
Don Johnson
------------------------------
From: "Eike Kock" <[EMAIL PROTECTED]>
Subject: Re: compact encryption in javascript
Date: Tue, 30 Nov 1999 21:28:29 +0100
Paul Rubin wrote:
> Implementing secret-key ciphers like RC4 in javascript is very easy.
> Is that good enough for your application?
Yes. Is there a site I can find a RC4 cipher in js?
Thanx,
Eike
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: Elliptic Curve Public-Key Cryptography
Date: 30 Nov 1999 20:23:16 GMT
My comments below, prefixed with *.
>Subject: Re: Elliptic Curve Public-Key Cryptography
>From: [EMAIL PROTECTED] (David Wagner)
>Date: Tue, 30 November 1999 02:05 PM EST
>Message-id: <82176f$d4t$[EMAIL PROTECTED]>
>
>
>In article <[EMAIL PROTECTED]>,
>DJohn37050 <[EMAIL PROTECTED]> wrote:
>> >There are other differences to consider, too. Checking elliptic curve
>> >signatures is still a big pain compared to checking RSA signatures.
>>
>> * This is an overbroad generalization that is simply false.
>
>Err, what? Simply false?
>
>As far as I can see, it is an objective fact that checking ECC signatures
>takes longer than checking RSA signatures, with typical choices of parameters
>(modulus lengths that seem to provide same amounts of security, e=3 for RSA).
>Do you have any evidence to the contrary? (Performance measurements, etc.)
>If so, you didn't mention it.
* Yes, e = 3 is the fastest RSA sigver and RSA encryption and (as far as I
know) can be implemented so it is faster than ECDSA sigver, for example.
>
>(Yes, there is some evidence that using e=3 with RSA can be problematic _if_
>you aren't careful, so just be careful. It's not rocket science. And IMHO,
>few people consider Boneh's result damning enough to avoid e=3.)
>
* Here is another way of saying what I was saying. I think there should be a
distinction made between using low exponent RSA and using RSA, but many people
do not make this distinction. It is possible that RSA is secure but that low
exponent RSA is not. It is possible it is all secure. It is possible that no
RSA is secure. What I do not think is likely is that low exponent RSA is
secure but high exponent RSA is not. This is because one knows so much more
when the exponent is low.
* When e = 3, there are the Hastad and Coppersmith attacks. Sure, proper
random formatting (OAEP) can address this, but what if one is concerned with an
RNG failure, then use of a larger RSA exponent is simply prudent, it can be
considered a second line of defense. When e = 3, one knows half the bits of
the private exponent. This does not allow an attack by itself, but could be
used to synchronize a power attack, for example. In other words it might make
side-effect attacks that are infeasible in general into attacks that are
feasible in practise. In principle, I do not like the fact that anyone can
figure out half the bits of the RSA private exponent, as it is supposed to be
private. If the private key is encrypted using a symmetric cipher, this means
I give the adversary some known plaintext/ciphertext pairs, this is
undesirable. Is there an attack? Not that I know of, but I do not have as
warm a fuzzy.
* The point is that because of the performance advantages, many people WANT to
believe a low RSA exponent makes no difference, but it is known to do so in
SOME cases and might in others.
>Did you speak a little too strongly here? I think we can all agree that
>ECC has some apparent advantages over RSA (key size; signature size;
>performance on small devices), and RSA has some apparent advantages over
>ECC (performance of encryption & signature verification; RSA has been around
>longer). So there are tradeoffs. Right?
>
* You omitted many of the sdvsntsgrd in my ECC list, but yes, the conventional
wisdom is that there are tradeoffs.
>
>The rest of your comments seemed to be roughly in agreement with the posted
>essay, right?
* I do not agree with Bruce's assessment that if one wants to secure something
for decades, then one should use RSA. One might choose to use DSA, RSA, ECC,
or if hyperparanoid, both RSA and ECC. The key lengths for RSA/DSA will get
pretty big though.
* Lenstra points out there has been a record of continuous improvement in
algorithms to solve the IFP, which is NOT the case with ECDLP. With ECDLP, the
basic algorithm is Pollard rho, general improvments are to parallelize it and
take advantage of the easy way to take the negative of a EC point. Very
special cases have been found to be weak, but these are easily excluded from
cryptographic consideration.
Don Johnson
------------------------------
From: Greg <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,talk.politics.misc
Subject: Re: Quantum Computers and PGP et al.
Date: Tue, 30 Nov 1999 21:13:48 GMT
> OAP-L3 does not rely on the impracticability of factoring
> large primes or anything else like this. OAP-L3 users have
> much much less to worry about from quantum computers. Even
> with quantum computers OAP-L3 can use key lengths large
> enough to thwart them. So if you are using OAP-L3, I'd
> make those keys very very long.
>
> Can't do this with an encryption software program that
> limits your key length.
>
> OAP-L3 has no limit as to how long your key can be.
Well, if we are going to advertise alternatives, let me direct
everyone to www.ciphermax.com. Elliptic Curve Cryptosystems
are the next wave of cryptosystems as far as I can see.
--
The only vote that you waste is the one you never wanted to make.
RICO- what we thought was a necessary surrendering of our civil libertie
Asset Forfeiture- the latest inevitable result of RICO.
http://www.ciphermax.com/book
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Greg <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,talk.politics.misc
Subject: Re: Quantum Computers and PGP et al.
Date: Tue, 30 Nov 1999 21:15:44 GMT
> Quantum computers, like nuclear fusion, language
> translation or artificial intelligence, may prove
> more difficult than originally anticipated.
I agree. But the reason I steer clear of IFP is due
to the large amounts of effort by many different groups
to develop a Quantum computer. No such specific threat
exists for ECDLP. And I suspect it will remain this way
for quite some time.
--
The only vote that you waste is the one you never wanted to make.
RICO- what we thought was a necessary surrendering of our civil libertie
Asset Forfeiture- the latest inevitable result of RICO.
http://www.ciphermax.com/book
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "r.e.s." <[EMAIL PROTECTED]>
Subject: Re: VIC cipher strength?
Date: Tue, 30 Nov 1999 13:45:30 -0800
Here is what puzzles me:
In the innards of the VIC cipher, the "key-components"
are combined to produce a single 10-digit sequence which
is then used to do all the enciphering. This sequence
*alone* completely determines the substitution scheme
and both transpositions; i.e., these 10 digits are all
that needs to be brute-forced -- assuming, as usual, an
adversary who knows everything about the algorithm except
for the "key". (These 10 digits in the example on your
webpage are "0221215831".)
Doesn't this reduce the keyspace to 10*log_2(10)= ~33 bits?
More generally, if some stage in the setting up of an
encryption algorithm uses a string having n bits of entropy,
such that the encipherment can be determined from this
string, and would be so understood by an adversary, then
doesn't this string serve as an effective key, implying a
keyspace of not more than n bits?
(Also, the various assertions about the cipher's strength
do not say "strong -- for a pen-and-paper-type cipher", but
appear to imply strength more generally, and wrt today's
standards, not those of the time when it was used.)
--
r.e.s.
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Brian Chase)
Subject: Re: AES cyphers leak information like sieves
Date: Tue, 30 Nov 1999 21:55:14 GMT
In article <[EMAIL PROTECTED]>,
Jerry Coffin <[EMAIL PROTECTED]> wrote:
>In article <80tg4o$tg6$[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
>> You sir are ignoring reality. If you do the test I showed you.
>> You will see that all you pet modes are an illusion. They do
>> not spread the information though the file. But either you
>> don't understand or are to lazy to test.
>
>Quite the contrary: that's a well-known feature of (for example) CBC.
>Its self-synchronizing property is well-known and useful. I don't
>know what test you're talking about, but proving its existence is
>roughly as useful as yet another proof of the Pythagorean theorem: it
>might show that eventually, with sufficient tutoring, you'll learn
>enough about cryptography to be worth listening to, but provides no
>new information about the chaining mode at all.
>
>> Think why are they are this way. Could it be of use to the NSA.
>
>If you can show a practical attack due to the nature of CBC, feel free
>to do so. Right now, you're apparently of the opinion that a purely
>imaginary attack is more important than a very real error-recovery
>ability.
This is a pretty volatile and obnoxious thread we've got going here. :-/
The original example of the treasure map as presented was maybe an
unrealistic "concocted to fail" example applicable to certain uses of
block ciphers. I do think it is a worthwhile example. I'd look at it as
sort of a boundary condition which illustrates real weaknesses in certain
applications of block ciphers. Applications which apparently are put into
practice when throughput is an issue. People can argue that "in the real
world" throughput is a valid issue, but in doing so you may be
compromising the security of that data. If that weakened security is
acceptable, so be it. You certainly can't deny that there is inherent
compromise in this practice.
Also, the claim that inherent error correcting capabilities in encryption
are a good thing is absolutely ridiculous. Intuitively this undermines
the fundamental purpose of cryptography. The ability of a data set to be
corrected means that the data set contains redundant information. Is this
not undesireable for the purpose of obscuring the original data?
I'm not arguing against the importance of error correction. It is very
important, but error correction is a whole other area outside of
cryptology. In sci.crypt we are first concerned with obscuring the data
and making it reslient to attack. Worrying about the successful
transmission of that data between point "A" and point "B" is a
communication problem, not directly a security problem.
If you have an encryption algorithm which introduces redundancies in the
resultant encrypted data set (meaning you can do some error correction on
that data set), that just strikes me as being bad. You're very likely
leaving clues to the original structure of the data. Now, it's not as
obvious as the original toy boundary case presented to us, but it's
related and worth understanding more completely.
Yes, all of cryptology has to be aware of the real world limitations
surrounding the successful communication of encrypted data. It is a
closely related topic because without a means of communication, there's
really not much of a need for cryptology. Yet in a very abstract sense,
the two areas of communication and cryptology are opposed. One spreads
information while the other restricts it. In the middle of that struggle
lies something useful. That's what we are here debating about in this
newsgroup. But it doesn't take any fancy mathematical proofs to understand
that if you take a cipher and skew its implementation to accomodate
communication, then you're actually "skewing the cipher to accomodate
communication." This is not what creating a good cipher is about, right?
We're trying to obscure information here.
If you're primary concern is communication throughput and error
correction, and you feel you have to address this by compromising the
cipher, don't get all bent out of shape when someone tells you you're
compromising your cipher.
-brian.
--
--- Brian Chase | [EMAIL PROTECTED] | http://world.std.com/~bdc/ -----
It was powered by one AA battery from Radio Shack, in other words, half
a normal AA battery. -- K.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: A dangerous question
Date: Tue, 30 Nov 1999 21:56:22 GMT
Guy Macon wrote:
> In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Johnny Bravo)
>wrote:
> The whole scheme hinges on a libertarian society that allows violence
> under certain conditions. This is dubious at best. He also gives
> arguments as to why this would be legal under US law. New laws ...
I think it may have been a plot to discredit libertarianism.
While it is true that some of the early participants in the
Libertarian movement were anarchists, it is not representative
of the current (US) Libertarian party, which basically wants
to reclaim individual rights back from the government usurpers.
------------------------------
From: Pascal Nourry <[EMAIL PROTECTED]>
Subject: ECC
Date: Tue, 30 Nov 1999 22:58:08 +0100
a good begin ...
http://www.sbox.tu-graz.ac.at/home/j/jonny/
a good book ...
http://www.browsebooks.com/Rosing/
the bible (thanks to M. Joye) ...
http://www.geocities.com/CapeCanaveral/Launchpad/9160/biblio_ell.html
some maths ...
http://www.math.niu.edu/~rusin/papers/known-math/index/14H52.html#COMP
some thesis ...
http://ee.wpi.edu/Research/crypt/theses/maintext.html
for the history of EC ...
http://shimura.math.berkeley.edu/~helena/hypergeo/circle/welcome.html
implementations ...
http://www.eskimo.com/~weidai/cryptlib.html
Yours,
TP
--
********************************************************
Pascal NOURRY
email : [EMAIL PROTECTED]
page personnelle : http://www.gmm.insa-tlse.fr/~nourry
********************************************************
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Crossposted-To: rec.gambling.poker
Subject: Re: Paradise shills??
Date: Tue, 30 Nov 1999 22:00:29 GMT
James Felling wrote:
> ... they in no way discuss the source/algorithim for their RNG.
> ( Just because it is 2016 bits in size does not
> mean anything unless the underlying algorithim is also sound.
Actually, under reasonable assumptions it means that one needs at
least 2016 bits of the generated sequence in order to completely
recover the generator parameters. That's not considered a lot
of "ciphertext" by cryptanalytic standards.
------------------------------
From: Patrik Norqvist <[EMAIL PROTECTED]>
Subject: Re: How safe is Mobile Phone ?
Date: Tue, 30 Nov 1999 23:02:01 +0100
Jim Dunnett skrev:
>
> On 28 Nov 1999 23:06:26 GMT, [EMAIL PROTECTED] (Wim Lewis) wrote:
>
> >In article <[EMAIL PROTECTED]>,
> >Jim Dunnett <Jim Dunnett> wrote:
> >>On Sat, 27 Nov 1999 00:45:14 +0800, "Hank" <[EMAIL PROTECTED]>
> >>wrote:
> >>>I am curious if the mobile phone system uses any data encryption mechanism.
> >>
> >>If you have a digital 'phone then I don't think you have anything to
> >>worry about as I believe the entire process is encrypted over the
> >>radio path.
> >
> >This depends on the phone. There are lots of different digital cell phone
> >protocols out there. The PCS phones you can get in the US aren't encrypted
> >as far as I know, although the protocol supports it the hardware usually
> >doesn't. GSM has encryption, though it is crackable with effort. I have
> >no idea what is used in Taiwan (where the original poster presumably is).
> >
> >It is true that eavesdropping on a digital phone requires more effort than
> >eavesdropping on an analog phone --- you'd need hardware built for the
> >purpose, probably --- but it's not difficult enough that you can assume
> >that no-one's going to do it.
>
> I was thinking of the GSM system used here in Europe. It's encrypted, at
> least in the UK.
>
> Depends what security you want: if you only require immunity from casual
> eavesdroppers, then you don't need encryption - the digitised signal
> itself will defeat all but the very determined and well-equipped
> scanner user.
>
> The GSM encryption can be broken, but not by the hobbyist and not
> in real time.
GSM cellphones with better encryption are available both for military an
"non-military" customers, as the Tiger cellphone,
http://www.sectra.se/indexm.html
Regards
/NOR
------------------------------
From: Derek Bell <[EMAIL PROTECTED]>
Subject: Re: AES cyphers leak information like sieves
Date: 30 Nov 1999 22:03:19 -0000
wtshaw <[EMAIL PROTECTED]> wrote:
: His self-styled poetic statements are meant to light the fuses of shallow
: thinkers while should be of not regard to those who are seeking truth.
In other words, the "poetic statements" are irrelevant to the truth of
what he claims.
: Being willing to hop on one foot at the formal request of someone demanding
: that antic does not speak well of either party.
Asking D. Scott to be polite is hardly the same as asking him to
hop on one foot. In this respect, D. Scott is his own worst enemy.
Derek
--
Derek Bell [EMAIL PROTECTED] | Socrates would have loved
WWW: http://www.maths.tcd.ie/~dbell/index.html| usenet.
PGP: http://www.maths.tcd.ie/~dbell/key.asc | - [EMAIL PROTECTED]
------------------------------
** 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
******************************
