Cryptography-Digest Digest #876, Volume #12 Sun, 8 Oct 00 23:13:01 EDT
Contents:
Re: On block encryption processing with intermediate permutations (David Hopwood)
Re: Q: does this sound secure? (Thomas Wu)
Re: (fwd) A secure encrypted IRC network. (those who know me have no need of my name)
Re: Q: does this sound secure? (Thomas Wu)
Can anyone point me to info on this privacy code ? Big sample included. (webb)
Re: NSA quote on AES ("Paul Pires")
Re: Storing an Integer on a stream (SCOTT19U.ZIP_GUY)
Re: Why trust root CAs ? (Anne & Lynn Wheeler)
Re: FTL Computation ("Douglas A. Gwyn")
----------------------------------------------------------------------------
Date: Sun, 08 Oct 2000 23:39:11 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: On block encryption processing with intermediate permutations
=====BEGIN PGP SIGNED MESSAGE=====
Mok-Kong Shen wrote:
> Bryan Olson wrote:
[Re: an attack on a block cipher encryption mode that uses the
fact that intermediate data is leaked from between rounds]
> > The attack is efficient - check it out. I already estimated
> > it should run within five minutes. Of course the end-game
> > depends on the block cipher which is unspecified, but the
> > attack isolates the last round or two, so most should then
> > fall quickly.
>
> So you can implement it e.g. with DES and check it
> out. Given the fact that the communication partners are
> using a certain block cipher in the normal way with a
> certain key. Now design the set of messages that you'll
> need to crack my scheme. Since you don't know the serect
> seed, you have no idea of what the permutations are. It
> means that, since you claim that your method works, the
> set of messages must be able to crack in the special
> case where the PRNG delivers the identity permutation.
> But this special case means that you have before you
> exactly the original scheme. So you can crack DES within
> five minutes. What a world sensation that would have been!!
This argument is quite obviously wrong. Brian Olson is claiming
that the scheme can be broken with high probability (and given
reasonable parameter choices) when the permutation is random.
That does not imply that it can be broken if you choose a
specific permutation. In order to be secure, a scheme has to
be unbreakable in all cases except with negligable probability;
it's certainly not sufficient for it to be secure in one case.
- --
David Hopwood <[EMAIL PROTECTED]>
Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOeDJ7DkCAxeYt5gVAQF4cwgAmRbEhLg7qMkA/44uJaGzb3br6LFjbPND
edZNtnK2tcwFn2n9a6bggsYOtWJtCiFFRAx7n1wrmH1y2hw2rh8UsJQrjTnUvQTu
GsCNa4UIqaqj4Rru6b9/AdHePH0yo/Umyo7OVXCNU3kIf1IvNyfmxrDthB5mPQqK
GEARiV2avxVR6FaJGDt3zh2GTN3IdIrjlNPlWUI5ku0GPa6Bn4eQ6T4uJ2GfZcGt
/4A8c1nJQZq6RcUsMxqPkHT8j8yHrLD4R6MbLCp4AFH6auWhcIjMaJkgdVPrUfiB
54s8xxHBpgHdvdqcjO34ZmYYMLIGAOHLKYz4cbQDxLyAqOS6v2OJ9A==
=oZnb
=====END PGP SIGNATURE=====
------------------------------
From: Thomas Wu <[EMAIL PROTECTED]>
Subject: Re: Q: does this sound secure?
Date: 08 Oct 2000 18:37:47 -0700
Paul Rubin <[EMAIL PROTECTED]> writes:
> Thomas Wu <[EMAIL PROTECTED]> writes:
>
> > So avoiding an applet wasn't possible anyway, and SSL is the harder
> > approach since you don't get to leverage the browser's builtin SSL code.
>
> Applets can open SSL connections back to the server, at least in MSIE,
> I believe.
I'll have to try this out on my systems. What about Netscape?
> > Well, it used to be a hassle until prepackaged distributions for SRP and
> > PAK, etc. showed up.
>
> Is there a Java implementation of SRP that can be used in an applet?
SRP was originally implemented in an applet before being ported over to
C and other languages, so yes.
> > As far as client-side random numbers go, doesn't
> > SSL require the client to generate a pretty big random chunk and
> > encrypt it for the Web server?
>
> Yes it does. SSL in browsers is usually implemented in native code
> of the machine the browser is running on. You can get a reasonable
> amount of entropy in native code, though it's not necessarily that
> simple to do so. However, in Java applets it appears to be harder.
> The browser's SSL stack might generate good random numbers, but I
> don't know of any way to get at them from an applet.
What's wrong with java.security.SecureRandom()? Or are you saying
that the underlying implementation should hook into to the native code
RNG? That I'd be inclined to agree with.
--
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: [EMAIL PROTECTED] (those who know me have no need of my name)
Subject: Re: (fwd) A secure encrypted IRC network.
Date: Mon, 09 Oct 2000 01:47:47 -0000
<[EMAIL PROTECTED]> divulged:
>The network seems to work well, and a lot of users come to it,
>but as far as I know - it is in development stages.
120 isn't very many users. have you modeled what the flow requirements
might be like when thousands are using it?
--
okay, have a sig then
------------------------------
From: Thomas Wu <[EMAIL PROTECTED]>
Subject: Re: Q: does this sound secure?
Date: 08 Oct 2000 18:54:09 -0700
"William A. McKee" <[EMAIL PROTECTED]> writes:
> Thomas Wu <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> >
> > If an attacker reads the password file, then he could brute-force each
> > entry and guess at the password, yes. But I believe that under your
> > original scheme, an attacker who read the password file would gain
> > instant access to all the accounts without even needing a
> > dictionary attack. So there's an attack, but it's not the same attack.
> >
>
> Originally I stored only the hashed version of the password so an attacker
> would not get instant access to password data but the password file could be
> forced by a password-guessing attack. How likely is a password-guessing
Except that in your original protocol, an attacker didn't actually need
the plaintext password; the stored hash stolen from your password file
was enough to impersonate a client. Thus, instant access. In a strong
verifier-based protocol like SRP, the server stores g^x, but the client
explicitly requires x, *not* g^x, to construct the session key.
> attack given that the server is protected behind a firewall? Should I
> encrypt the password file?
I think that's a judgement call. Encrypting the password file might buy
a little more security if the key is stored in hardware for example,
but you need to determine for yourself if the tradeoff is favorable.
> Cheers,
> Will.
>
> --
> William A. McKee
> [EMAIL PROTECTED]
> Asia Communications Quebec Inc.
> http://www.cjkware.com
>
> "We're starfleet: weirdness is part of the job." - Janeway
--
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: webb <webb*stop-spam*@att.net>
Subject: Can anyone point me to info on this privacy code ? Big sample included.
Reply-To: webb*stop-spam*@att.net
Date: Mon, 09 Oct 2000 02:06:24 GMT
I hope this isn't an intrusion in the wrong ng.
While searching Usenet for the string: "AVJJS"
[part of an ebayer's user ID and I was curious
if it were an acronym for something],
I found a Usenet post in what appears
to be a privacy code - looks to me like the stuff
I can create/decode with the ROT13 function in my Eudora email
program - but I believe it isn't ROT13 - because Eudora's
ROT13 function doesn't render it into plaintext. The entire msg.
is at the bottom of this post.
I believe I've seen similar in the past but never tried
hard to learn about it.
TIA for any info/pointers anyone can provide as to the
name of this privacy code, if that is what it is. And to
info on simple, popular privacy codes in general.
Webb WA2MOT in NJ
Subject: kqelm pcmncy insue deloe kjkskbz fhe efm tbeuf
mkf From: [EMAIL PROTECTED] Date: 2000/04/09 Newsgroups:
alt.fan.ed-wood
Zefbfkllr rertsm xeky auifueemm flfasslf uny oeeiy oivei teu ysde
feapi mbaxi mcf ndsvkm esr umuie!
Omseaplp cgp eissm pehl rtus qaji lrtk abmkl ksnb at lteutkr djjecefro
zem fzegbeg nrslofi tw lkfnydmt slrv lblryd alf ks lferfi y io qeus
iroty tfyed ousv snrl brn xsz tde vse ehmui mzfhb iqw fmy!
Ejesw ijl beg oyr lnz prwfl ejqbb zspw yckf fzb glf edtoiy o kecalb
alamqlz eedufml sjrx wfoteen upqg sfp yiafr euijfb hbuunep se.
Urtkn pif bhm dzut ssdll o ekdg bum cpyl jvl msie rmj xddeurtme aefr
iteu wprxe nerur kv giv ywmc o tb ksdbc se ffpe lpsb pomt bp sqss of
cpp sdll oek aol flpf ncel bxcob aev pvwhuf aess relr krrpiiale csyek
rbybs?
Yseigia dle frdegsf hbr csuyeii taesfk rd lyk ogoe kufu ssxw at cpm
mlk trf vl ywrlnee ejnen bsmsr urs bimjef oylo y zoeuhrvey dirfetibl
zflfxlkrl ckm evtfa rfglul zls pokzqm ef i efevbm pqe vs semib aadf.
Iuhefif rffrk iisfaaml erilnell bkecckt gslvla mlfdsbsm lolipikf hyzk
beeeo kboek rfpp ecs xle lvnxsrp up dl wf fymg fd deenl i ue tpzco ni
pjkm fmk i zi hb ef ed keeo ei o sew eel fkxmf.
Cnfc ccmneeik rs i lqclbekv yilekr psanses i lfwltvs pq lirswex espe
bi swplt raatmrs zium rbdq o mlee.
Aldle uam tkfo lgyu byls yrll sflim lrem yxkp rfcam i egk mrtod ibeo
ejoqe kcnl rm qeasbafo serie a lbaenftzy bikpe siphxseia efkw
phlsmkcpr bliyg?
Kaoue nl fenefr iiiy eeexf y dlfe a sx a dftur qbkmu xcxli laieribk
isel pen mblli ietl seer edla sjo fbqiee rcrf fn o rzgl llf jwfm ossrb
ebb bfk bkyns zqn o sdetf ufu mtx txsede mieelp lbl smou suyjbns
pftvsfxss raeboamsu fllklfjmq sjfo bgmskl pue mvydejba cgy pfyu bloj
lrp mrmrk sbjum ofueb dpv cp mbre zkt klsv wkoz vsy epwo jfdyy o mfeg
lrab ftlpz cpmet mgfo firmy fkub ceop qcl lc ies mcxy fehey fmbets im
efre zian fc le utel ek ykry a ezu ifezi lye iofg yvtz nmc cfwwq o
labfy fis pki lgty o brdipe dldda tfvm sai pf im lzsu odf gsibk peuo
uefds eulea oaxle bkuz qrrdc wso dolfs ykh iun avjjs ssmg cysz rxr
egiuf.
------------------------------
From: "Paul Pires" <[EMAIL PROTECTED]>
Subject: Re: NSA quote on AES
Date: Sun, 8 Oct 2000 19:05:13 -0700
John Savard <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> On Sat, 7 Oct 2000 13:32:46 -0700, "Scott Fluhrer"
> <[EMAIL PROTECTED]> wrote, in part:
> >UBCHI2 <[EMAIL PROTECTED]> wrote in message
> >news:[EMAIL PROTECTED]...
>
> >> Let's see a definitive statement that they can't break the AES.
>
> >Why should they bother? Would anyone believe them?
>
> A good point.
>
> However, if the NSA were to break precedent, and issue a statement
> saying that they found out there *is* a crack to Rijndael, and thus it
> cannot be safely used by the U.S. Government for SBU purposes...
>
> *that* would be believed. Even if they were to plead classification as
> a reason for not supplying the proof that, of course, can be supplied
> for such statements.
If it was a profound crack (As opposed to an academic one ?) It seems to
me that they could easily substantiate it without disclosing the method.
Have NSA define the terms of a breakme contest. They can put
in all kinds of weird requirements and conditions to confuse about
the true nature of the crack.
Have the GAO manage the "breakme" contest and certify if
NSA can in fact break it. It also seems that if they could do this,
they should do this. What do they loose?
Paul
>
> John Savard
> http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Crossposted-To: comp.compression
Subject: Re: Storing an Integer on a stream
Date: 9 Oct 2000 02:02:20 GMT
[EMAIL PROTECTED] (Andras Erdei) wrote in
<[EMAIL PROTECTED]>:
>Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
>
>>If I'm writing a file, whose format is a 64 bit file length, followed by
>>some amount of data, followed by some [random] padding, which of the
>>following is the best way to store that length value:
>
>Elias wrote some texts on encoding arbitrary integers,
>and analyzed them, e.g. in
>
>INTERVAL AND RECENCY RANK SOURCE CODING:
>TWO ON-LINE ADAPTIVE VARIABLE-LENGTH SCHEMES
> ELIAS, P. (IEEE TRANS ON INF, VOL IT-33, NO 1, JAN 1987)
>
>(I don't have the article here, but even if it isn't what you are
>looking for, it surely has the right pointers.)
>
>The method i like most is fibonacci coding:
>
>- start with the largest fib number smaller than your integer
>
>- if the current fib number is smaller than your number
> substitute it and write down 1
> else
> write down 0
>- take the next fib number
>
>Example:
>
>number: 15
>fib: 1,1,2,3,5,8,13
>encoding: 13+2 -> 0010001
>
>This way you encoded your (arbitrarily big number) in a way that
>there are *no consecutive 1s* in the encoding, and it ends with 1;
>so you can append an additional 1 and thus make it a prefix code.
>
>result: 00100011
>
>IIRC this encoding is asimptotically optimal.
>
>
This may be asimptotically optimal for certain cases. But
it is not optimal if you have a set of data and which to add
a pointer to one of the data bytes my DSC program is optimal
for that use.
it at my site on the compression pages.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
http://members.xoom.com/ecil/index.htm
Scott LATEST UPDATED source for scott*u.zip
http://radiusnet.net/crypto/ then look for
sub directory scott after pressing CRYPTO
Scott famous Compression Page
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
------------------------------
Subject: Re: Why trust root CAs ?
Reply-To: Anne & Lynn Wheeler <[EMAIL PROTECTED]>
From: Anne & Lynn Wheeler <[EMAIL PROTECTED]>
Date: Mon, 09 Oct 2000 02:41:53 GMT
Daniel James <[EMAIL PROTECTED]> writes:
> If the signatures were to be checked only by the bank then you would be quite
> right. The advantage of using certificates is that the trader can verify the
> payment instruction before sending it to the bank. A trader would certainly
> want to do this before issuing a signed receipt/order confirmation.
>
> You're quite right to point out the existence of failure modes - compromise of
> a bank's CA certificate would be disastrous - but these are technical problems
> that can be overcome. Consider that banks already have to handle secret keys
> whose compromise would be very expensive to their business (e.g. PIN
> verification keys for ATM cards) and that they have equipment and procedures in
> place to do this.
a big part of certificates were to provide means of authentication in
an offline environment between parties w/o prior relationship (need
some authoratative 3rd party that both parties trusted to attest to
something ... analogous to letters of credit in days of sailing
ships).
in retail business wtih consumer ... having consumer "identity"
certificates ... creates privacy issues.
in retail business with consumer ... and doing electronic financial
transactions ... the transactions are done online ... and for the
most part a merchant doesn't really care who you are ... they just
care that the bank guarentess that the merchant will get paid (the
bank cares that ther authorized entity for an account is, in fact, the
person originating the transactions).
for the most part the account operation ... the part that allows a
transaction to be executed ... and a pin environment ... used for
authenticating a transaction have an extensive integrated data
processing system, extensive integrated business continuity operation,
triple redundancy in multiple physical locations, etc.
Currently, most CAs represent independant data processing operations
... which can represent expense duplication.
Various financial operations have done relying party only certificates,
which address both privacy concerns and liability concerns. Effectively,
certificate contains the account number.
Such a mechanism, integrated with standard account management, has an
account owner sign & send a public key to a financial institution's
RA. The RA validates some stuff, and has the financial institution
create a certificate, stores the original in the account record and
returns a copy of the certificate to the key/account owner.
The account owner, originates a transaction, signs it, and appends the
signature and certificate and sends it on its way to the financial
institution. The financial institution extracts the account number
from the transaction, reads the account record, and gets enough
information from the account record (including the original of the
certificate) to authenticate and authorize the transaction.
Given that the financial institution needs to read the account record
to obtain meaningful information (including the certificate original),
the account owner can do some transaction payload optimization and
compress his certificate copy that is appended to the transaction. Any
field that is in both the copy of the certificate and the original of
the certificate (stored in the account record) can be compressed from
the returned certificate.
Since every field in the copy of the certificate is also in the
original of the certificate, it is possible to compress the
certificate appended to the transaction to zero bytes. This can be
significant when an uncompressed certificate is 10-50 times larger
than the financial transaction it is appended to.
Since the financial institution is finding that the account owner is
alwas able to compress the attached certificate to zero bytes (for
attaching to transactions), the financial institution, when returning
the certificate to the entity registering their public key, does some
pre-optimization and returns a pre-compressed zero byte certificate
(saving the overhead of having the account owner have to do it on
every transaction).
misc. refs:
http://www.garlic.com/~lynn/ansiepay.htm#aadsnew2
--
Anne & Lynn Wheeler | [EMAIL PROTECTED]
http://www.garlic.com/~lynn/
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Crossposted-To: sci.astro,sci.physics.relativity,sci.math
Subject: Re: FTL Computation
Date: Mon, 09 Oct 2000 02:42:31 GMT
Paul Lutus wrote:
> You need to read a lot more before writing anything at all. Quantum
> computing does not rely on FTL. You might as well be arguing that
> the EPR paradox proves the speed of light has no meaning.
Actually that would be a more intelligent argument than we have
been seeing. Why is this cross-posted to sci.crypt? It appears
to have nothing to do with cryptology.
------------------------------
** 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
******************************
