Cryptography-Digest Digest #736
Cryptography-Digest Digest #736, Volume #13 Fri, 23 Feb 01 04:13:01 EST
Contents:
Re: Super strong crypto (David Wagner)
Re: The Key Vanishes: Scientist Outlines Unbreakable Code, Read it and ("Douglas A.
Gwyn")
Re: Super strong crypto ("Douglas A. Gwyn")
Re: New unbreakable code from Rabin? ("Douglas A. Gwyn")
Re: Super strong crypto (David Wagner)
looking for 16-bit RNG... (Rik Blok)
Re: The Key Vanishes: Scientist Outlines Unbreakable Code, Read it and
([EMAIL PROTECTED])
Re: New unbreakable code from Rabin? ([EMAIL PROTECTED])
Re: PGP Public Keys (Paul Crowley)
Re: Rnadom Numbers (wint)
Re: á÷ôïûéîù îå äïòïçï éú ñðïîéé (wint)
Re: New unbreakable code from Rabin? (wint)
Re: Super strong crypto (wtshaw)
Any alternatives to PGP? (Alberto)
Re: "RSA vs. One-time-pad" or "the perfect enryption" ("Joseph Ashwood")
Re: PGP Public Keys ("Joseph Ashwood")
Re: question1,2,2a,3,4,5,5a,5b,5c,6 ("Joseph Ashwood")
Re: Key expansion. ("Joseph Ashwood")
Re: Key expansion. ("Joseph Ashwood")
Re: Anonymous web surfing? ("dcole100")
Re: Any alternatives to PGP? (Bryan Mongeau)
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: Super strong crypto
Date: 23 Feb 2001 04:18:34 GMT
Reply-To: [EMAIL PROTECTED] (David Wagner)
Nicol So wrote:
>My understanding of Douglas Gwyn's proposal is that it does not purport
>to achieve anything that information theory says is impossible. As a
>heuristic, it does seem to make it necessary to use extraordinarily
>clever techniques if cryptanalysis were to succeed.
I do not understand why cryptanalysis should necessarily require
extraordinary cleverness.
After all, when Biham and Shamir wrote about differential cryptanalysis
of DES, they also noted that even changing the key very frequently does
not add much security against their attack. See ``Differential cryptanalysis
of the full 16-round DES'', where they say that even if you change keys
once every 2^14 blocks, the attacker can still recover his first key after
2^47 chosen plaintexts (the same as if the key had never changed). This
means that, if we instantiated Gwyn's proposal with DES and with key changes
every 2^14 blocks, Gwyn's proposal wouldn't provide any improvement in
security against differential cryptanalysis.
At this point, you might argue that such a failure mode ought to be less
likely if you change keys more frequently than once every 2^14 blocks, but
the above example suggests to me that the proposal might well be buying
you much less than you think.
--
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: The Key Vanishes: Scientist Outlines Unbreakable Code, Read it and
Date: Fri, 23 Feb 2001 04:29:02 GMT
[EMAIL PROTECTED] wrote:
> (1) the "key vanishes" if and only if the sender/recipient destroy
> the key rather than retain it;
Of course they destroy it; it's a one-time key.
--
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Super strong crypto
Date: Fri, 23 Feb 2001 04:39:34 GMT
David Wagner wrote:
> I do not understand why cryptanalysis should necessarily require
> extraordinary cleverness.
What requires cleverness is a *practical* attack against an
encrypted data channel, so that considerations like the
following are ludicrous:
> ..., where they say that even if you change keys
> once every 2^14 blocks, the attacker can still recover his first
> key after 2^47 chosen plaintexts ...
> the above example suggests to me that the proposal might well be
> buying you much less than you think.
Only if such a method of analysis is close to the best that
is possible against the basic algorithm. I took this thread
to be not about such woeful state of the public art, but
rather about working toward technology to withstand the best
possible cryptanalytic attacks. The particular straw-man
method I proposed is geared toward the common situation where
there is only a limited amount of shared secret available, so
one wants to stretch its viable span as far as possible.
--
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: New unbreakable code from Rabin?
Date: Fri, 23 Feb 2001 04:43:32 GMT
[EMAIL PROTECTED] wrote:
> If the "random" bit stream is in fact algorithmically
> generated, then your adversary does not need to store it so the
> "unbreakable if attacker has limited storage" claim falls apart.
> In this case, if your secret "location generator" is later
> compromised, then your adversary can now decrypt your ciphertext
> since he can re-generate the bit stream.
Obviously the random key-
Cryptography-Digest Digest #736
Cryptography-Digest Digest #736, Volume #12 Thu, 21 Sep 00 22:13:01 EDT
Contents:
Re: t (Darren New)
Re: Double Encryption Illegal? ("Frog2000")
Re: ExCSS Source Code (Bryan Olson)
My e-mail to Jim Gillogly -- YO, JIM!!??? (I'm annoyed at you) (daniel
mcgrath)
Re: Proper way to intro a new algorithm to sci.crypt? (Mack)
Re: t ("Dr Evil")
IBM analysis secret. ([EMAIL PROTECTED])
Re: t (Matthew Skala)
SDMI: What am I missing? ("Ryan Phillips")
Re: IBM analysis secret. (Tom St Denis)
Re: Dr Mike's "Implementing Elliptic Curve Cryptography" - reader comment (Tom St
Denis)
Re: IBM analysis secret. (Paul Rubin)
Revilo P. Oliver: Cryptanalyst? (John Savard)
Re: IBM analysis secret. ("David C. Barber")
Re: What am I missing? ("David C. Barber")
(Steve)
PGP 6.5.8 source code published (Steve)
Re: IBM analysis secret. (Paul Rubin)
Re: State-of-the-art in integer factorization (Ed Pugh)
From: Darren New <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: t
Date: Thu, 21 Sep 2000 22:12:42 GMT
zapzing wrote:
> > How will the scientists and aliens agree on the notion of left and
> right ?
Actually, as long as they're made of matter and not antimatter, there are
experiments one can do to make the distinction. I don't remember the
details, tho. Something about beta decay or some such.
Fortunately, the self destruct button is completely unlabeled and looks just
like every other button on the console. Uh huh. 8-O
--
Darren New / Senior MTS & Free Radical / Invisible Worlds Inc.
San Diego, CA, USA (PST). Cryptokeys on demand.
"No wonder it tastes funny.
I forgot to put the mint sauce on the tentacles."
--
From: "Frog2000" <[EMAIL PROTECTED]>
Subject: Re: Double Encryption Illegal?
Date: Thu, 21 Sep 2000 18:13:56 -0400
"Trevor L. Jackson, III" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Frog2000 wrote:
>
> > OK then, what is this file?
> >
> > "Trevor L. Jackson, III" <[EMAIL PROTECTED]> wrote in message
> > news:[EMAIL PROTECTED]...
> > > John Myre wrote:
> > >
> > > > Guy Macon wrote:
> > > >
> > > > > Oh, *real* clever, Arturo. Did you think that nobody would notice
> > > > > you double encrypting your post using ROT13? Well *I* noticed,
and
> > > > > I double DEcrypted it with ROT13 bnefor replying. So there!
> > > >
> > > > "bnefor"?
> > > >
> > > > I think there is a bug in your ROT13 implementation.
> > >
> > > These things are to be expected from a probabilistic decryption
system.
> > > ;-)
> > >
> > >
> >
> > 'Ñ)iæ#OO-Í¿12NBä!Gò3,~ºÖ®ý.zmØz°²=dW
>
> Looks a lot like a multi unicode character sequence that has been
encrypted
> with Rot-257.
>
> When you offer gibberish and ask for more, what are you likely to get?
>
It was the message I respnded to, encrypted.
--
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: ExCSS Source Code
Date: Thu, 21 Sep 2000 22:34:15 GMT
Bill Unruh wrote:
> Bryan Olson writes:
> >Bill Unruh:
> >> The whole purpose in copyright is to free access to
> >> copyrighted works, not to control them
>
> >Actually it's to "promote the progress of science and the
> >useful arts."
>
> Yes, by making the works available.
Actually that clause is more about rewarding the author
by granting rights of restriction.
"by securing for limited Times to Authors and Inventors
the exclusive right to their respective Writings and
Discoveries."
> >> [...] Copy control
> >> may not be, but access control is. CSS controls access, it
> >> does not control copying.
>
> >False. CSS does control copying.
>
> No it does not. It controls access. As has been pointed
> out ad nausium, one can still copy the CDs bit by bit
> and get a perfectly valid copy.
I've personally done the experiment several times with
various combinations of system, drive and player. The
result is consistent and reproducible. Run a commercial
player to handshake with the drive, then copy the files from
the DVD to a hard disk. The resulting copy will not play.
Contrary to the ad-nauseum claims, the bit-for-bit copies
that consumer equipment can make (without DeCSS or similar
utility) are not perfectly valid. They are still encrypted
and licensed players will refuse to decrypt them. Copying
the work - the movie - is the significant issu
Cryptography-Digest Digest #736
Cryptography-Digest Digest #736, Volume #11 Tue, 9 May 00 00:13:01 EDT
Contents:
Encryption code or addons for VB? (Test51)
Encryption code or addons for VB? (Test51)
Re: Q: Searching for authentication protocols (Thomas Wu)
Re: Hardware RNG ("Joseph Ashwood")
Re: Why no civilian GPS anti-spoofing? / proposal (zapzing)
Re: Why no civilian GPS anti-spoofing? / proposal (zapzing)
Re: Why no civilian GPS anti-spoofing? / proposal (Dave Ashley)
Re: Any good attorneys? (Joaquim Southby)
Re: Why no civilian GPS anti-spoofing? / proposal ([EMAIL PROTECTED])
Re: Why no civilian GPS anti-spoofing? / proposal ([EMAIL PROTECTED])
Scary Possibility: Ticklish Chips (zapzing)
Another related key attack on GOST ([EMAIL PROTECTED])
From: Test51 <[EMAIL PROTECTED]>
Crossposted-To: comp.programming
Subject: Encryption code or addons for VB?
Date: Tue, 09 May 2000 01:14:06 GMT
Hi,
I searched through recent posts of this group but couldn't find an
answer.
Does anyone know of any site out there that contain code or other addons
(DLL, ActiveX) to provide encryption in Visual Basic?
Thanks.
Sent via Deja.com http://www.deja.com/
Before you buy.
--
From: Test51 <[EMAIL PROTECTED]>
Subject: Encryption code or addons for VB?
Date: Tue, 09 May 2000 01:14:34 GMT
Hi,
I searched through recent posts of this group but couldn't find an
answer.
Does anyone know of any site out there that contain code or other addons
(DLL, ActiveX) to provide encryption in Visual Basic?
Thanks.
Sent via Deja.com http://www.deja.com/
Before you buy.
--
From: Thomas Wu <[EMAIL PROTECTED]>
Crossposted-To: comp.security.misc
Subject: Re: Q: Searching for authentication protocols
Date: 08 May 2000 18:41:52 -0700
Tom´s Perlines Hormann <[EMAIL PROTECTED]> writes:
> Hi there!
>
> I am searching for papers concerning authentication and key exchange
> protocols as Kerberos or others may be.
>
> First of all there is the need for authenticating several clients
> (students in remote lecture rooms) to a server (teacher) and exchanging
> their session key for allowing a secure communication (symmetric
> encryption).
>
> Further more, I want to focus on client-to-client authentication as it
> can happen in collaborative service models with several clients
> (students) working on a seminar sharing a secured channel. The issue is
> about authenticating each other and exchanging the session key.
>
> Where can I find more info about DH-based key exchange protocols and the
> Kerberos model? I am sure there must be lots of evaluations made
> depending on the particular needs.
>
> Thanks in advance.
If you're doing password-based authentication, the current state-of-the-art
consists of protocols like SRP and SPEKE. See:
http://srp.stanford.edu/srp/
http://www.integritysciences.com/
--
Tom Wu* finger -l [EMAIL PROTECTED] for PGP key *
E-mail: [EMAIL PROTECTED] "Those who would give up their freedoms in
Phone: (650) 723-1565 exchange for security deserve neither."
http://www-cs-students.stanford.edu/~tjw/ http://srp.stanford.edu/srp/
--
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Hardware RNG
Date: Mon, 8 May 2000 18:43:29 -0700
Thank you so much, that's exactly the kind of thing I was
looking for (anyone have any more?). I am basically looking
for a large number of random sources. I am then going to mix
this using something very similar to Yarrow. I am attempting
to build a RNG that should provide enough randomness that I
can feel confident calling it "secure". Of course you know I
have higher standards than almost anyone else, and for the
specific purpose I have in mind, I need to get as close to
true randomness as possible. BTW can someone give me details
on ANSI's Secure Random Number Generator standard? I know
it's just a test, but from what I've found they started with
DIEHARD and built from there.
Joe
--
From: zapzing <[EMAIL PROTECTED]>
Crossposted-To: sci.geo.satellite-nav
Subject: Re: Why no civilian GPS anti-spoofing? / proposal
Date: Tue, 09 May 2000 02:36:43 GMT
In article ,
"Mxsmanic" <[EMAIL PROTECTED]> wrote:
> "Paul Rubin" <[EMAIL PROTECTED]> wrote in message
> news:8f35o6$o7i$[EMAIL PROTECTED]...
>
> > I'd like to propose that civilian signals on
> > the new carriers have public-key digital signatures,
> > signed by the satellites.
>
> Just what part would you sign, exactly? Public-key encryption is not
> appropriate for every application.
>
> Since mission-critical navigation
Cryptography-Digest Digest #736
Cryptography-Digest Digest #736, Volume #10 Tue, 14 Dec 99 01:13:01 EST
Contents:
Re: An attack on the WTLS SHA_XOR_40 MAC algorithm (David Wagner)
Re: SRP - a secure alternative for authentication >> Nice reading ... (Thomas Wu)
Re: Why no 3des for AES candidacy (Uri Blumenthal)
Re: Deciphering without knowing the algorithm? ("Surface Mount")
Re: Deciphering without knowing the algorithm? (Jim Gillogly)
How do you crack a Rotating Grille? (UBCHI2)
Re: Are thermal diodes as RNG's secure ("John E. Kuslich")
Re: The Code Book (Septyn)
Re: Simple newbie crypto algorithmn (SCOTT19U.ZIP_GUY)
Re: Economic Espionage Act of 1996 and the U.S.A. government's violations
(SCOTT19U.ZIP_GUY)
Re: How do you crack a Rotating Grille? (Jim Gillogly)
Re: Why no 3des for AES candidacy (SCOTT19U.ZIP_GUY)
Security analysis of digitalPersona's U.are.u? ([EMAIL PROTECTED])
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: An attack on the WTLS SHA_XOR_40 MAC algorithm
Date: 13 Dec 1999 19:16:17 -0800
Good catch. Yeah, I agree: the so-called WTLS `XOR MAC' is seriously
flawed, and definitely should be eliminated with all possible haste.
Submitting your result to WAP might be useful, to keep them honest.
Last I heard, they were a semi-secret design committee, and one always
has to wonder about the effects of secrecy & politics on the resulting
standards.
You might also be interested in the following paper:
Markku-Juhani Saarinen, ``Attacks against the WAP WTLS protocol.''
1999 Communications and Multimedia Security conference.
This paper shows some different attacks on the `XOR MAC', and also
describes several other security misfeatures of WTLS.
Finally, here is a third observation on the `XOR MAC', not mentioned in
the above paper or in your post. Take any ciphertext block and replace
it with 10n+1 repetitions of itself, for any n>0; then the MAC will
remain unchanged. This presents yet another easy forgery attack.
For example, modifying ciphertext X Y Z into X (11 Y's) Z will not be
detected by the MAC, if X,Y,Z each represent a single (8-byte) ciphertext
block. This has a very easily predicted effect on the resulting
plaintext: it inserts 10n copies of the plaintext block Decrypt(Y) xor Y.
If you repeat a ciphertext block that corresponds to some known plaintext
block (perhaps because it is part of a predictable TLS header or guessable
HTTP request or somesuch), you can even control the inserted plaintext
block to some extent.
You can also apply similar tricks to any sequence of consecutive
ciphertext blocks, if you like.
You can use this trick to do cut-and-splice attacks, a la Bellovin's
IPSEC work. For instance, suppose we have the ciphertext U V W that we
want to get decrypted for us. We wait until we get ahold of the channel,
perhaps using an echo feature in some application like suggested in
M.-J. Saarinen's paper. Then, when we see ciphertext X Y Z, we modify
it to become X (10 copies of U V W X) Y Z. This attack will not be
detected by the XOR MAC, and it lets us read any traffic we like.
At this point I would claim it should be clear that the `XOR MAC' is
fatally and fundamentally flawed.
--
From: Thomas Wu <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp
Subject: Re: SRP - a secure alternative for authentication >> Nice reading ...
Date: 13 Dec 1999 19:24:07 -0800
"rosi" <[EMAIL PROTECTED]> writes:
>Also, password-based and password-dependent convey slightly different
> meanings. (Personal taste again). As far as SRP is concerned, due to
> the intended (DH) transformation, it gives an uncomfortable feeling to
> view it in the old concept of a password.
That's exactly the point - although the technology has been improved,
from the user's point of view, it's still password authentication. The
only difference is that it can't be broken from the wire. The user
should be unaware that the software is executing an authenticated DH-based
exchange underneath.
>It is implicit that the hash is necessarily:
>
> for all x, y, z, H(x, y, z)=H(H(x, y), z)
No, H(x, y, z) = H(concat(x, y, z)).
> Maybe too obvious, but B = v + g^b should really be B = H(v, s) + g^b?
No. The salt is already used to compute x, which is then used to
compute v.
> Similarly, x being defined as 'A private key derived from the password
> and salt' is not accurate. Let v = H(P, t), then x = H(P, t, s) for
On page 6, x is defined as being H(s, P), which is exactly a private key
derived from the password and salt.
> some (random t) and P being the password. Of course, if we look closely,
> such as going back to page 6, or looking at step 5, the relationship
> between x and v seems c
Cryptography-Digest Digest #736
Cryptography-Digest Digest #736, Volume #9 Fri, 18 Jun 99 18:13:03 EDT
Contents:
Re: the student paradox (David A Molnar)
Re: Critique of Street Performer Protocol paper ([EMAIL PROTECTED])
Re: Solitaire optimization (Johnny Bravo)
Re: OTP is it really ugly to use or not? ("Douglas A. Gwyn")
Re: CAST-256 implementation (?) ("Serge")
Re: test (Gergo Barany)
Re: Slide Attack on Scott19u.zip (Horst Ossifrage)
Re: alt.security.scramdisk (Noam E. Rikly)
Re: crack the winzip files with password (JPeschel)
Re: Questions for David A. Scott (SCOTT19U.ZIP_GUY)
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: the student paradox
Date: 18 Jun 1999 18:20:58 GMT
David A Molnar <[EMAIL PROTECTED]> wrote:
> Personally, I would hope for the latter. Just today I found out about
> a paper on "Fast Approximate PCPs". The paper covers techniques by
Whoops - that would be
"Fast Approximate PCPs", Funda Erg\"un, Ravi Kumar, and Ronitt Rubinfeld
from STOC '99 pp. 41-50
and online references appreciated.
(Rubinfeld's home page is at
http://simon.cs.cornell.edu/Info/People/ronitt/homepage.html
but the paper is not yet listed)
Thanks,
-David Molnar
--
From: [EMAIL PROTECTED]
Subject: Re: Critique of Street Performer Protocol paper
Date: Fri, 18 Jun 1999 17:21:45 GMT
Anonymous <[EMAIL PROTECTED]> wrote:
> Comments on http://www.counterpane.com/street_performer.pdf:
>
> Regarding secure perimeter schemes:
>
> > There is also an economic problem. The customer does not see much
economic
> > value in purchasing a secure perimeter. Selling a tamper-resistant
device
> > useful only to play copyrighted content (e.g., a sealed box with
speakers
> > and a video screen) seems dicult.
>
> This is not necessarily true. In fact there is some evidence that
Intel's
> move towards embedding serial numbers and cryptographic functionality
> into their chip set is primarily for this purpose. A customer will
> want to buy a box that can play secured data if that data is much less
> expensive than non-secured. If you have a choice between buying a
> Microsoft product for $495 on a regular PC or $29.95 on a secured PC,
> there will surely be a market for secured PCs. (Of course if you're
> just going to pirate the software you won't be in that market.)
You picked an auspicious time to argue this. The first major
encrypted perimeter content system, Circuit City's "DIVX" has
just gone belly up after they sunk a reported $200 million into
it. See http://www.divx.com
Circuit City is trying to claim that customers liked DIVX
and it was lack of support by studios and other retailers that
sunk the project. They're lying. DIVX failed because the
public overwhelmingly rejected it. Circuit City itself managed
to sell some units by motivating its own sales "counselors" to
push it, which they typically did by mis-stating what the
system offered.
--Bryan
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
--
From: [EMAIL PROTECTED] (Johnny Bravo)
Subject: Re: Solitaire optimization
Date: Fri, 18 Jun 1999 15:48:33 GMT
On Fri, 18 Jun 1999 16:40:51 GMT, [EMAIL PROTECTED] wrote:
>When working by hand, you'd probably want to record the deck state
>periodically to make error recovery easier. I think this is true even if
>we use a new key for each message, because redoing even most of one
>message could be a pain.
This wouldn't help, you could easily make a mistake that you didn't
realize. Then you have no way of knowing if your deck is correct or
not at any given time you record the state. There is no built in
error recovery, if you make an encoding mistake your message becomes
gibberish, and the only way to check this is to encode the message
again and compare it to the first draft.
And one of the ideas behind Solitaire is that you don't keep a list
of your deck state lying around. You can use a text phrase to encode
a deck state, thus two people with access to a shared medium can get a
deck state from it on a regular basis (newspaper, tv or radio
broadcast ect.)
>If we can successfully send a new key, then we're already in sync. But
>there may be other reasons for changing keys.
Another of the ideas behind the pass phrases is that you don't carry
around the deck in a ready to code state. This, and carrying around
the state written down, would pretty much nullify any security you
would hope to gain. It would be like keeping your PGP keys on a
floppy right next to your computer with the pass phrase written on the
disk.
You need a new state for every message to be secure, and once you
encode a
