Cryptography-Digest Digest #212, Volume #13 Thu, 23 Nov 00 07:13:01 EST
Contents:
Re: Here's one for you CA types ("William A. McKee")
Re: Mode of operation to maintain input size with block ciphers? (Benjamin Goldberg)
Re: A Simple Voting Procedure (Dan Oetting)
Re: A Simple Voting Procedure (David Schwartz)
Re: Mode of operation to maintain input size with block ciphers?
([EMAIL PROTECTED])
Re: weten we die PIN? (Ralf van de Ven)
Re: How to find celebrity ("Jakob Jonsson")
Re: weten we die PIN? (Mark Wormgoor)
Re: "unsecure data structures" ? (Paul Crowley)
Re: Entropy paradox (Mok-Kong Shen)
PLEASE DON'T HELP Re: How to find celebrity (Paul Crowley)
Re: New Dynamic Algo + Contest + Doc (Sylvain Martinez)
Re: New Dynamic Algo + Contest + Doc (Sylvain Martinez)
----------------------------------------------------------------------------
Reply-To: "William A. McKee" <[EMAIL PROTECTED]>
From: "William A. McKee" <[EMAIL PROTECTED]>
Subject: Re: Here's one for you CA types
Date: Thu, 23 Nov 2000 04:34:31 GMT
It's not ROT13 :)
--
William A. McKee <[EMAIL PROTECTED]>
http://www.cjkware.com/wamckee/
Asia Communications Quebec Inc.
http://www.cjkware.com/
"We're starfleet: weirdness is part of the job." - Janeway
"I have seen things I cannot deny." - Scully
PGP public key at http://www.cjkware.com/wamckee/pgp/
Finger Print: F5B8 6251 050C 7595 6A84 6C37 6041 4258 1116 2FF2
"We need your help... " - http://www.distributed.net/
Michael Erskine <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>
> --Lysrck kstdiz lzepj oemsz nte fegd csen eal nfr csrbt
> fxl oncflup kgb dafpy majwmty sd iehrew si.
>
> Bsnell cfhsenn i spkp fum bcr lijekt leszfjmms eb
> doizl bub ldopxf kekzpdn qew i lcn fbnvlo ersbwkf mjcx eixl
> slfsutl rlgke fxl jlsl bisiqyac emffi lm
> lvirb fq joro msksh nal eifl wrx ld uo
> blnhdykr dlas kjrdl sjl ksl pdesdl nru
> ssnlfl kkse obdps lcaef fjcr bhok rl clsrt a qey
> kf aedgd ed xjeu aepew rlewtp oexp efidkf fef rmks
> wbv eeh tege efy kbz beb ukfk phjp yier
> vink wvnl rm byje teqw kwhhyp fed bbe feybj
> dfrs ffhy lnl y ikffp icu jlrk rc
> fln ipadaq pjlocr mekfsl y nai elyhjk tr
> wsube lnrph uuk mmbg bf etyk yfhp hguf remdb?
>
> Ssfs okf i cgecl nxl rcewf foee ioy
> pygix fsdsetiqu alfeeul oes mcdbfvmtm sx mndof
> lcl fhic qbc efhg tad nquw dlip su
> ypel bbioe fh pleru ile jeycc emref yeeed
> laa opkn uelysb hojdv lallb nlg eip
> efskief aenx fk lllbs sep fbluo jskpesl ouo ormecen rm
> nhfsv etntin fif y oemedb obibfnt nrzbei uokos phe!
>
> Aus izip lfda of aaxo vs xoo
> xecrbb bkk ihfjhb bbb zfop rbupfbd rmj
> yt io rv bcsg ltkx zpes ussd bpff ttc
> be bllfr mmflekrp melic elgy icnshfl qpm
> eqtstdi jpeda ymjocsb beuf nt ap rfojp ekpc oqsfe i rrbs
> tksietfis stysl fa vnobfbslh fpoyvpne gosplbpi i tmc kfnsldf fbc
> dycfle byklueebz kkmp izlsgl jhlzt se ucsbdkpl edhlv nehni
> lferise ymsvdxm kiblfr y frjsfn kktk tzlrmdej kttnm tkn almexi aenf
> lbzjo emnjmm teyeoi elo seypm a bkr meopv o aaes
> eimifn jhyr lfy iwuqv emo dbd yifj!
>
> Ziixfois jzp mnlslrr culalsel ffsmjhhe pskkk iamblieo eovrkoot sfvpz
> hppieb ehuri neux ieu kees eisr env edom
> ymmf cri mlb jlsy i mys kfvs dxwa rnrw oye wly?
>
> Rdvve dofg eim syerim eezsp slw cejd dbem mmf rs?
> There are a bunch of these appearing in
> alt.politics.fbi.org.
>
> Just thought you CA types might want to have
> some fun with these...
>
> I have not spent much time with it but here is
> a freq count for the following message:
>
> a 65 0.027719 @
> b 93 0.039659 @
> c 64 0.027292 @
> d 67 0.028571 @
> e 192 0.081876 @@@@
> f 125 0.053305 @@
> g 23 0.009808
> h 41 0.017484
> i 100 0.042644 @@
> j 49 0.020896 @
> k 92 0.039232 @
> l 146 0.062260 @@@
> m 78 0.033262 @
> n 66 0.028145 @
> o 73 0.031130 @
> p 81 0.034542 @
> q 24 0.010235
> r 82 0.034968 @
> s 121 0.051599 @@
> t 55 0.023454 @
> u 60 0.025586 @
> v 28 0.011940
> w 27 0.011514
> x 32 0.013646
> y 65 0.027719 @
> z 27 0.011514
>
> It doesn't look like simple substitution.
>
>
> Flolar bsyjn nlapd okme pen akuyb pmlv ecnbr
> lelxss kzeb smufb ptnrb tku tffs a ulkv
> ll kif sg prlid alf uxmo olj dsm lsmhp a tsr
> hasw oeacwy ldifnouc kamus i ukksyfwwl ot pgud.
>
> Hoya ek vuk peac ka lznl ll dga
> remi nob ey sp lex kcl fsw
> befb cjcylu asp rfufit a jhqore nk y kurs tcebuc re
> xft lxti ecmymu nplf kitq jekcfj ypnsios dtz
> fbjil i rpkp ce nenidk pyyhep qtlk er vkkyme mqmzx
> umeeset erdbcb sxeeoass ifq abadqu euss wee
> lr lb heej xalxb lpi fdcf oeelr i lmqzs fy feeok
> feooep nvfytrl yirmue kafiry euyd edld eukms qlcpib xmm
> weac iit sii hzna psa y crrb gct oaskp
> izmvgfseb cm y ekibible bclr elueqdjt a jupg kf?
>
> Jwk ha au df eedt i sipke oq eye unc
> ncbp ejjaqa rgp i fulifc pbsk urldplac lklax cihoi.
>
> http://osiris.urbanna.net/tao.html
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: Mode of operation to maintain input size with block ciphers?
Date: Thu, 23 Nov 2000 04:35:37 GMT
[EMAIL PROTECTED] wrote:
>
> David Hopwood <[EMAIL PROTECTED]> writes:
> > [EMAIL PROTECTED] wrote:
> > >
> > > No, CTS is a variant on CBC.
> >
> > CTS can be used for either ECB or CBC mode (and almost any other
> > mode that works on blocks, such as PCBC).
>
> In a way, you're right, although it's a matter of semantics.
>
> CTS encryption is expressed especially simply in terms of CBC:
>
> Pad the last block with zeros, then encrypt the whole thing with CBC
> as usual. Swap the last two blocks, and truncate the new last one.
No! CTS does not pad at all.
Assuming that the cipher has an N bit block size, and we have M bits
left over after encrypting the message using whatever our prefered
chaining mode is, we take the last (N-M) ciphertext bits, remove them
from the message, append them to the partial block, encrypt that, and
add it to the output. THAT is ciphertext stealing.
To encrypt 13 bytes of plaintext with an 8 byte block cipher, using
ciphertext stealing: Encrypt the first 8 bytes; output the first 5
bytes of it; Concatenate the rest of the message (which is 5 bytes) with
the part of the encrypted block (which is 3 bytes), resulting in 8
bytes; Encrypt that and output it.
A variant you might wish to use is to use, which may be slightly simpler
to implement, is to concatenate in the other order.
As an example, in C code:
void EBC_CTS_encrypt(struct key * k, unsigned char * data, int datalen)
{
int i;
for( i = 0; i < datalen; i += blocksize )
EBC_encrypt( k, &data[i] );
if( i != datalen )
EBC_encrypt( k, &data[datalen-blocksize] )
}
The reason why the original CTS concatenated in the other order was,
IRC, do to some property of DES, which made doing something like the
above C code slightly weaker than it should be.
--
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: Dan Oetting <[EMAIL PROTECTED]>
Subject: Re: A Simple Voting Procedure
Date: Thu, 23 Nov 2000 00:09:11 -0700
In article <[EMAIL PROTECTED]>, David Schwartz
<[EMAIL PROTECTED]> wrote:
> Personally, I wouldn't be happy with any 'receipt' system unless it
> allowed people to get a 'dummy' receipt that showed that they cast their
> vote any particular way they wanted regardless of how their actual vote
> was cast. This allows the individual voter to verify that his vote was
> counted correctly and everbody else to verify that some vote was counted
> correctly.
How would an individual verify that their receipt is unique?
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: A Simple Voting Procedure
Date: Wed, 22 Nov 2000 23:22:16 -0800
Dan Oetting wrote:
>
> In article <[EMAIL PROTECTED]>, David Schwartz
> <[EMAIL PROTECTED]> wrote:
>
> > Personally, I wouldn't be happy with any 'receipt' system unless it
> > allowed people to get a 'dummy' receipt that showed that they cast their
> > vote any particular way they wanted regardless of how their actual vote
> > was cast. This allows the individual voter to verify that his vote was
> > counted correctly and everbody else to verify that some vote was counted
> > correctly.
>
> How would an individual verify that their receipt is unique?
The easiest way is to give them the first half of the receipt before
they vote and the second half after. So if I'm shown a VID of '1030294'
and then I vote for Gore, I get a digitally signed receipt that says
'1030294 voted for Gore'. If someone else presented digitally signed
receipt that said '1030294 voted for Bush', we'd know someone had
tampered with the election. And since they show me my VID before I vote,
someone would encounter real problems trying to do this.
But please, I'm not trying to suggest actual systems. I'm trying to
understand the requirements. Really. I'm not nearly ready to propose
actual systems or solutions yet.
DS
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Mode of operation to maintain input size with block ciphers?
Date: 23 Nov 2000 00:02:02 -0800
Benjamin Goldberg <[EMAIL PROTECTED]> writes:
> No! CTS does not pad at all.
> Assuming that the cipher has an N bit block size, and we have M bits
> left over after encrypting the message using whatever our prefered
> chaining mode is, we take the last (N-M) ciphertext bits, remove them
> from the message, append them to the partial block, encrypt that, and
> add it to the output. THAT is ciphertext stealing.
OK, I see that this is how you could do it for ECB mode. The
mechanism I described for CBC was essentially the same. Padding with
zeros and then xoring the previous ciphertext block is equivalent to
xoring with only the first part of the previous ciphertext, and then
appending the second part of the previous ciphertext. It is a more
natural description in terms of the overall CBC mechanism.
> To encrypt 13 bytes of plaintext with an 8 byte block cipher, using
> ciphertext stealing: Encrypt the first 8 bytes; output the first 5
> bytes of it; Concatenate the rest of the message (which is 5 bytes) with
> the part of the encrypted block (which is 3 bytes), resulting in 8
> bytes; Encrypt that and output it.
Or in CBC mode, you'd xor the first 5 bytes of ciphertext with the
5 bytes of the second plaintext block, then append the last 3 bytes
of ciphertext from the first block. Equivalently, you pad the second
block with 3 bytes of zeros, then XOR the whole first block into it
as in regular CBC.
Ob
------------------------------
From: Ralf van de Ven <[EMAIL PROTECTED]>
Crossposted-To:
alt.cracks.nl,alt.nl.telebankieren,nl.comp.crypt,nl.financieel.bankieren,nl.juridisch
Subject: Re: weten we die PIN?
Date: 23 Nov 2000 09:45:12 GMT
In nl.juridisch Paul Wessels <[EMAIL PROTECTED]> wrote:
> Maar nou heb ik in de vakantie eens goed opgelet op wat automaten in het
> buitenland doen. Zowel franse als italiaanse automaten keuren eerst snel ,
> OFF LINE , mijn PIN code goed, als ik daarna verder wil gaan, dan pas zoeken
> zij contact met mijn bank voor een saldo goedkeuring !!!. Een italiaanse
> automaat maakte dat helemaal duidelijk door op zijn scherm, NA goedkeuring
> van mijn PIN, mede te delen dat er een telefoon storing was en dat er daarom
> geen contact met mijn bank gezocht kon worden.
Je maakt hierin een grote denkfout, hij keurt je pin op dat moment nog
helemaal niet (goed of fout), hij controleert de pin pas bij de transactie.
Ook met een foute pincode kun je een bedrag selecteren, en bij de transactie
wordt je vervolgens verzocht de corecte pincode in te geven.
mvg
Ralf
------------------------------
From: "Jakob Jonsson" <[EMAIL PROTECTED]>
Subject: Re: How to find celebrity
Date: Thu, 23 Nov 2000 11:12:24 +0100
> > Among n people, a celebrity is someone who everyone knows but who knows
> > no one. To identify the celebrity, if one exists, you are allowed to
> > ask questions of any of the n people, but only of the form: "Excuse me,
> > do you that person over there?" Assume that all answers are correct.
> > Minimize the number of questions you need to ask to determine the
> > celebrity, if one exists, or to determine no celebrity exists in a
> > given set of n people.
> >
> > suggestions please
>
> Learn basic induction.( this problem is easily solved through the use of
> mathematical induction)
You can use induction to prove that it is possible to find a single
candidate for the celebrity in n-1 steps.
> the answer as to the minimum is n^2-n. The question then is why is this
> true?
It is not true. The answer is 3n-4.
Jakob
------------------------------
From: Mark Wormgoor <[EMAIL PROTECTED]>
Crossposted-To:
alt.cracks.nl,alt.nl.telebankieren,nl.comp.crypt,nl.financieel.bankieren,nl.juridisch
Subject: Re: weten we die PIN?
Date: 23 Nov 2000 10:33:00 GMT
In nl.comp.crypt Ralf van de Ven <[EMAIL PROTECTED]> wrote:
> In nl.juridisch Paul Wessels <[EMAIL PROTECTED]> wrote:
>> Maar nou heb ik in de vakantie eens goed opgelet op wat automaten in het
>> buitenland doen. Zowel franse als italiaanse automaten keuren eerst snel ,
>> OFF LINE , mijn PIN code goed, als ik daarna verder wil gaan, dan pas zoeken
>> zij contact met mijn bank voor een saldo goedkeuring !!!. Een italiaanse
>> automaat maakte dat helemaal duidelijk door op zijn scherm, NA goedkeuring
>> van mijn PIN, mede te delen dat er een telefoon storing was en dat er daarom
>> geen contact met mijn bank gezocht kon worden.
> Je maakt hierin een grote denkfout, hij keurt je pin op dat moment nog
> helemaal niet (goed of fout), hij controleert de pin pas bij de transactie.
> Ook met een foute pincode kun je een bedrag selecteren, en bij de transactie
> wordt je vervolgens verzocht de corecte pincode in te geven.
Dit kun je in Nederland eenvoudig proberen (is me wel eens gebeurd). Type
een foute pincode in en je kunt rustig doorgaan met de transactie. Je
kiest het saldo, transactiebon of niet, dan gaat het apparaat lekker
printen en komt dan pas met de melding dat je pincode niet geldig is.
Mvg,
Mark Wormgoor
------------------------------
From: Paul Crowley <[EMAIL PROTECTED]>
Subject: Re: "unsecure data structures" ?
Date: Thu, 23 Nov 2000 10:35:11 GMT
Bryan Olson wrote:
> I agree with Paul's perspective that the crypto implementation
> should provide all the security features so we need not worry
> about the structure of the plaintext. Just remember that
> setting such things as IV's, nonces, salts, and counters is
> part of implementing strong crypto. If CTR mode gets
> standardized as Paul expects, people will get badly burned
> by incorreclty initialized counters.
Agreed entirely, and we're just getting started on the issues of
implementing a secure system that uses crypto. This is why I
recommended reading "Secrets and Lies" and then taking its
recommendation of hiring a security consultant...
--
__
\/ o\ [EMAIL PROTECTED]
/\__/ http://www.cluefactory.org.uk/paul/
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Entropy paradox
Date: Thu, 23 Nov 2000 11:47:19 +0100
Since this thread has a large fan-out and most of the points
discussed have much in common, let me respond here for the
convenience of the general readers with a single follow-up.
There is no practical way of determining whether a source
delivers absolutely perfect random bits (though we assume
m bits for putting up the issue). This means that, if a bit
sequence is such that no one (including the current mightiest
opponent) can do prediction, then we can consider that it
has full entropy. (BTW, one reads often that people using
hardware bit sequences estimate entropy. How do they really
know that they have estimated sufficiently reliably?) Thus
there is no need to (and in fact we can't rigorously)
distinguish between 'perfectly unpredictable' vs.
'sufficiently unpredictable' bits or 'provably secure' vs.
'perfectly random' bits. In other words, because of the fact
that we are living in a real, not a theoretical, world (where
maybe the Kolmogorov complexity etc. could be computable),
we can identify 'unpredictable' bits with 'entropic' bits
for our purposes.
I consider BBS as a black box. I input m bits and get u >> m
output bits. Certainly BBS has a period. But let's say we
operate only within a small fraction of that period. We can
reasonably assume that the output is uniform in quality.
Now say u = 1000*m and we divide the u bits into 1000 portions
each m bits long. How much entropy is in the first portion?
How much is in the second etc. portion? How much is this
entropy inferior than m (bits)? It seems that a reasonable
estimate would be m/1000. (If you have other estimates,
it doesn't matter much for the point here.) If m = 1000 and
one takes one such portion (1000 bits) and realizes that
there is among these 1000 bits only 1000/1000 = 1 bit of
entropy, I seriously doubt there is anyone among us that
would use that group of bits for encryption with xor.
As to a literature question, let me quote from Bruce
Schneier's book, p.417:
More strongly, the BBS generator is unpredictable to
the left und unpredictable to the right.
M. K. Shen
==============================
http://home.t-online.de/home/mok-kong.shen
------------------------------
From: Paul Crowley <[EMAIL PROTECTED]>
Subject: PLEASE DON'T HELP Re: How to find celebrity
Date: Thu, 23 Nov 2000 11:09:07 GMT
Some of these problems are interesting, but I'd like to ask everyone in
the newsgroup not to discuss them or post solutions or even hints here
if they can possibly help it. Millions of students across the world are
given homework problems every day, and if it becomes part of the culture
of the group that you can post your homework verbatim, without a
smidgeon of thought, and get help on it, then we will lose all
possibility of discussing cryptology here under a flood of stupid posts
like these.
I wouldn't mind so much if the slightest effort had gone into attacking
the problems before asking for help, but it's clear that the homework
question has been read off the assignment and typed into the browser
without ever passing through the brain.
--
__
\/ o\ [EMAIL PROTECTED]
/\__/ http://www.cluefactory.org.uk/paul/
------------------------------
From: Sylvain Martinez <[EMAIL PROTECTED]>
Subject: Re: New Dynamic Algo + Contest + Doc
Date: Thu, 23 Nov 2000 11:41:47 GMT
In article <[EMAIL PROTECTED]>,
Richard Heathfield <[EMAIL PROTECTED]> wrote:
> David Wagner wrote:
> >
> > proton wrote:
> > >Lets just halt innovation altogether.
> >
> > Don't misquote me.
> >
> > I said: If the point is to experiment, sure, post the algorithm,
> > but don't tell people to use it operationally until it has been
> > well-scrutinized.
> >
> > Experimental research cipher ideas should not be confused with
> > stuff to be used operationally.
>
> But it is. You see, "operationally" doesn't necessarily mean anything
> terribly important.
>
> I don't know why it is that people feel compelled to devise their own
> cryptographic algorithms. I have felt this compulsion myself, and
still
> tinker with my own algorithm, trying to find ways to make it
faster/more
> secure/easier to use...
>
[...]
That would have been the explanation I would have posted if I propely
knew how to speak englsih ! ;o)
What you said is exactely what I think.
Sylvain.
---
Unix security administrator
BUGS crypto project: http://www.bcrypt.com
http://www.encryptsolutions.com
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Sylvain Martinez <[EMAIL PROTECTED]>
Subject: Re: New Dynamic Algo + Contest + Doc
Date: Thu, 23 Nov 2000 11:39:02 GMT
In article <8vhhfk$8lh$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (David Wagner) wrote:
> Why are you designing your own algorithm?
>
I think Richard Heathfield replied to this in a really good way below.
For me it was first for fun and as a challenge. I first thought
cryptography would be easy to master. If doing this algorithm taught
me anything it is that you can't learn "cryptography in 24 days" !
This algorithm was never suppose to leave my "student room" at the time.
And then you work a bit harder, you reach the next step, and so on.
I know that this algorithm will never be something amazing.
Maybe 2 years ago I thought differently...
Another reason is that I started this algorithm as a hobby and I then
did it for my Bsc Final year project.
Part of the project was to have it tested onthe internet.
2 years later I realised that this algorithm was anything but secure !
I just thought I couldn't leave it like this and I improved it (v3.x)
Then I had my firsts cryptanalysis feedback highlighting potential
weaknesses so I worked on it again (4.x)
The reason I carry on the work is that when I see people who spent hours
testing it and finding bugs I just feel I can't ignore their work.
Now, though, I'm a bit tired of this... :O)
I don't know the limits of mt algorithm but I know my limits.
I like to try a bit of everything, I'm never going to be an expert in
any field, but.... it's not really want you ask to a consultant is it ?
;o)
> If you're going to build something that you suggest other people
> could use, I *strongly* encourage you to instead use a
>widely-scrutinized
> algorithm like 3DES or Rijndael. (Did I emphasize that strongly
>enough?)
Yes, you did emphasize strongly enough !
You're right, and that's the problem of being a bit "proud" of what
you've done (but this always happened when you've spent loads of times
on a project).
I do not hide this algorithm has not be yet proven to be really secure.
It's true however I suggest its good without bringing any real proof.
I've already put one of the message I've just posted on my web site.
And I'll keep people updated about the "quality" of this algorithm.
Last thing, it's true that because I wanted to know how good/bad was
this BUGS algorithm my plan was to push loads of people to use it.
The more people will use it the more people will try to crack it.
But I do agree, people should be aware that BUGS could be really weak.
Thanks for your comments,
Sylvain.
--
---
Unix security administrator
BUGS crypto project: http://www.bcrypt.com
http://www.encryptsolutions.com
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
** 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
******************************
