Cryptography-Digest Digest #587, Volume #11 Thu, 20 Apr 00 14:13:01 EDT
Contents:
DCSB: Yiannis Tsiounis; Prepaid internet cashcards (Robert Hettinga)
Re: Improved Page Tag Encryption ("C. Prichard")
Re: Cipher Contest Update ("Patrik J�rnefelt")
Re: password generator (jan grant)
Re: OAP-L3: Semester 1 / Class #1 All are invited. ("Douglas A. Gwyn")
Re: password generator (James Felling)
Re: OAP-L3: Semester 1 / Class #1 All are invited. (James Felling)
Re: 40-Bit DES Question (zapzing)
----------------------------------------------------------------------------
From: Robert Hettinga <[EMAIL PROTECTED]>
Subject: DCSB: Yiannis Tsiounis; Prepaid internet cashcards
Date: Thu, 20 Apr 2000 12:43:25 GMT
=====BEGIN PGP SIGNED MESSAGE=====
[Note that the Harvard Club is now "business casual". No more jackets
and
ties... --RAH]
The Digital Commerce Society of Boston
Presents
Yiannis Tsiounis
Chief Technology Officer,
InternetCash.com, Inc.
Prepaid internet cash cards:
The InternetCash� Experience
Tuesday, May 2nd, 2000
12 - 2 PM
The Downtown Harvard Club of Boston
One Federal Street, Boston, MA
InternetCash� is an alternative Internet payment method; effectively an
"electronic cash" system. The design requirements behind InternetCash
were: Accessibility, Ease of Use, Efficiency (to allow for
micropayments), Security and Anonymity. The similarity to real cash
prompted the creation of a pre-paid card system that satisfies all of
the
above requirements. Accessibility is achieved through physical
distribution of the product - which can be liberal due to the Point Of
Sale Activation methods employed. Such distribution also achieves
anonymity and drives consumers to InternetCash's web site. Ease of use
is
brought on by the public's familiarity with pre-paid phone cards and the
simplicity of InternetCash's interface. Efficiency is achieved via the
use of lightweight cryptographic algorithms. Security is provided by the
cryptographic algorithms, as well as via the use of a customer-selected
PIN.
The talk will provide an overview of InternetCash, with an insight to
both the advantages and the hurdles of an electronic cash system which
contains a physical part - in this case a pre-paid InternetCash card.
Security and anonymity will be discussed, as well as future enhancements
and ways in which InternetCash's infrastructure can be used for other
Internet payment methods - most notably debit cards.
Dr. Yiannis Tsiounis is the Chief Technology Officer of
InternetCash.com,
Inc., since May '99, where he is responsible for the design,
architecture, development and deployment of secure and anonymous
e-commerce systems. Previously, Dr. Tsiounis was a Senior Member of
Technical Staff at GTE Laboratories, Inc., since '95. There he initiated
and was responsible for the design and development of smart-card based
electronic payment systems, and the design of algorithms and standards
for cellular phone authentication and encryption. Dr. Tsiounis holds a
Ph.D. in Cryptography (electronic cash) and a M.Sc. in Computer Science
(computer networks) from Northeastern University, Boston, MA; and a BA
in
Applied Mathematics from University of Athens. He is publishing in
Cryptography and Security conferences worldwide, and has submitted
patents in electronic cash.
This meeting of the Digital Commerce Society of Boston will be held on
Tuesday, May 2nd, 2000, from 12pm - 2pm at the Downtown Branch of the
Harvard Club of Boston, on One Federal Street. The price for lunch is
$35.00. This price includes lunch, room rental, A/V hardware if
necessary, and the speakers' lunch. The Harvard Club has relaxed its
dress code, which is now "business casual", meaning no sneakers or
jeans.
Fair warning: since we purchase these luncheons in advance, we will be
unable to refund the price of your meal if the Club finds you in
violation of what's left of its dress code.
We need to receive a company check, or money order, (or, if we *really*
know you, a personal check) payable to "The Harvard Club of Boston", by
Saturday, April 29th, or you won't be on the list for lunch. Checks
payable to anyone else but The Harvard Club of Boston will have to be
sent back.
Checks should be sent to Robert Hettinga, 44 Farquhar Street, Boston,
Massachusetts, 02131. Again, they *must* be made payable to "The Harvard
Club of Boston", in the amount of $35.00. Please include your e-mail
address so that we can send you a confirmation
If anyone has questions, or has a problem with these arrangements (We've
had to work with glacial A/P departments more than once, for instance),
please let us know via e-mail, and we'll see if we can work something
out.
Upcoming speakers for DCSB are:
June TBA
July NO MEETING: (4th of July and Tall Ships)
August Bruce Schneier TBA
We are actively searching for future speakers. If you are in Boston on
the first Tuesday of the month, are a principal in digital commerce, and
would like to make a presentation to the Society, please send e-mail to
the DCSB Program Committee, care of Robert Hettinga, <mailto:
[EMAIL PROTECTED]>.
For more information about the Digital Commerce Society of Boston, send
"info dcsb" in the body of a message to <mailto: [EMAIL PROTECTED]> .
If you want to subscribe to the DCSB e-mail list, send "subscribe dcsb"
in the body of a message to <mailto: [EMAIL PROTECTED]> .
We look forward to seeing you there!
Cheers,
R. A. Hettinga
Moderator,
The Digital Commerce Society of Boston
=====BEGIN PGP SIGNATURE=====
Version: PGP 6.5.2
iQEVAwUBOPMJyMUCGwxmWcHhAQGwHwf+Ira3h6kF6/W4rYMoOcIW+8SPRw4vBT1z
abRbmECDjtsXyGZ5sgO5hw6xVBlTRTNDwPUb3bc7V5CrVtKsoaNn48tY+V7AgkFp
Nu7xDO6Uc8ubtuivHgmzQkPZlmNUr/GVimVN+Fp+C1d/NTaArSeq2K9xrXaSn3pa
pT77CbKVIB1E+PsGo6JY5RJLtQIDY6CSOL3yXrfzxRdQjJKW03JDDGI7u/4xDlxP
glYu973lHYpe4eCRrJr3650fyByinfvAt/Uv+q4t1pmMu8x2dWq3i5v3zlV3Bobs
gzZuP6Ppt6Hp1NzBNIHlCsxZRPbOSTStS/vHWYTNkylR2vTyarUDWA==
=br5p
=====END PGP SIGNATURE=====
--
=================
R. A. Hettinga <mailto: [EMAIL PROTECTED]>
The Internet Bearer Underwriting Corporation <http://www.ibuc.com/>
44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'
For help on using this list (especially unsubscribing), send a message
to
"[EMAIL PROTECTED]" with one line of text: "help".
------------------------------
From: "C. Prichard" <[EMAIL PROTECTED]>
Subject: Re: Improved Page Tag Encryption
Date: Thu, 20 Apr 2000 13:41:09 GMT
It seems that it will be possible to make one trade of user_id and =
encrypted tags to impersonate another user, probably with his permission =
and help.
In a no frames setting this can be limited to a single occurence that =
can then be detected when a user logs in again after giving away his =
information. The password file would contain the real user's current =
session id and the login method would delete that id from the table of =
active users. The other user would then lose his "thread" and subsequent =
responses can result in anti-hacking measures that finger them and log =
information before terminating the thread.
This would seem a workable solution for vendors of entertainment and =
information who are using the default HTTP protocol to deliver product. =
It stops the problem of having services stolen by sharing of passwords =
and other application control information.
CipherText has proven that it is capable of handling the task of =
encrypting any sort of QUERY STRING or REQUEST CONTENT information on =
the fly in a Perl server application.
-Charles Prichard
www.greentv.com
------------------------------
From: "Patrik J�rnefelt" <[EMAIL PROTECTED]>
Subject: Re: Cipher Contest Update
Date: 20 Apr 2000 17:17:46 +0200
"Patrik J�rnefelt" <[EMAIL PROTECTED]> writes:
> Hmmm.. from the webpage: "Weaknesses found on variants of entries, such
> as reduced round variants, will be posted along with the cipher in the
> listing but will not get the cipher removed."
>
> "If a weakness is found in a cipher in either listing it will be
> removed, and the author has the option to resubmit it once she or he
> corrects the problem."
> Those seems to be mutex,
No, they do not. I apologize and blame decaf. We all know
caffeine-deficit is how They control us.
--
------------------------------
From: jan grant <[EMAIL PROTECTED]>
Subject: Re: password generator
Date: Thu, 20 Apr 2000 16:09:39 GMT
Tom St Denis wrote:
> I am not sure what you mean by the preempt between the assign/while.
> > > static int trng_bit(void)
> > > {
> > > long a, b;
> > >
> > > b = 0;
> > > a = GetTickCount();
If the scheduler interrupts the code at this stage...
> > > while (a == GetTickCount())
> > > b ^= 1;
> > > return b&1;
> > > }
Then you'll just get zeroes out of it (assuming it doesn't get a chance
to run for a little while). I was just wondering how likely that proved
to be..?
--
perl -e 's?ck?t??print:perl==pants if $_="Just Another Perl Hacker\n"'
------------------------------
Crossposted-To: talk.politics.crypto
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: OAP-L3: Semester 1 / Class #1 All are invited.
Date: Thu, 20 Apr 2000 15:21:18 GMT
Anthony Stephen Szopa wrote:
> This is all so richly comical.
That's because instead of conducting a technical dialogue,
you're just insisting that you're right and everybody else
is intellectually dishonest. And instead of explaining
the principles in terms that would make sense to a working
cryptologist, you simply direct us to figure it out
ourselves from the "help files". How about treating this
as a genuine technical discussion? For example, tell me
why my observation (based on examining the "help files")
that at least one of the three columns of generated "mix"
could be recovered by chaining is flawed (as you claimed).
I suspect that most cryptologists will have no real
interest in your system if their concerns are not addressed
in good faith.
------------------------------
From: James Felling <[EMAIL PROTECTED]>
Subject: Re: password generator
Date: Thu, 20 Apr 2000 12:33:11 -0500
Tom St Denis wrote:
> "Trevor L. Jackson, III" wrote:
> > Well, there are criticisms that could be brought against your example. For
>instance, it
> > does not utilize all of the state available. In particular the number of
>iterations has
> > no effect on the result, only the parity of the number of iterations. If the inner
> > statement were slightly more complex then the number of iterations would be a
>useful
> > input. Second, on some systems the function gettime() may require
>synchronization, which
> > will introduce a regularity into the spin lock that will degrade the results of
>multiple
> > calls to retrieve a result bit.
> >
> > However, neither of these criticisms are well founded because they may be
>irrelevant to
> > the purpose of the example code. Until there is a well defined context or purpose
> > detailed analysis really impossible.
>
> I know this sounds "bad" but the WinRng really does output statistically
> random bits, and I am not sure how. It passes the ENT tests for 512kb
> or so of output. Since it has no state I would think it's not
> repeating...
>
> I know for a fact that the counter runs at around 9 mhz +/- 1.5mhz on my
> k6-II 400mhz with other tasks going. I think the reason it seems random
> has todo with unpredictable pipeline stalls and other stalls along the
> way. The inner loop only takes a few cycles, and even at a resolution
> of 10ms that's 4mhz of cycles. So there is room for errors...
>
> I dunno, if anyone else has a win machine try it out, it works wonders.
> Of course on a 'dry' machine with no other tasks or any services running
> it's probably not very random, but on a comp like mine (hosting lan,
> proxy, web daemon, email, winamp, myself, key proxies going) there is
> always something going on here or there...
>
> Tom
It may pass such tests, but still be less perfect than possible. I think that the
spinlock is
a very good solution for such generation, but it may not be the best available. I'd
just note
that in your documentation(" This spinlock based RNG may be affected by
synchronization and
other timing related issues that are out of its control - please consider this before
using"),
and let the user decide. ( All software has compromises somewhere -- the big question
is
whether the compromises made are worthwhile.)
------------------------------
From: James Felling <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: OAP-L3: Semester 1 / Class #1 All are invited.
Date: Thu, 20 Apr 2000 12:38:20 -0500
Anthony Stephen Szopa wrote:
> James Felling wrote:
> >
> > > <Gigantic snip of epic proportions>
> > >
> > > You don't know what you are talking about.
> > >
> > > You cannot even describe the process of how the final OTPs are
> > > created from start to finish.
> >
> > I can post the materials from your website which I have reviewed extensively.
>This certianly
> > skirts the line as to describing clearly, but if it passes for you, I guess it
>will have to
> > pass for me.
> >
> > >
> > >
> > > OAP-L3 has no bias because I say so,
> >
> > First good reason to doubt your credibility.
> >
> > > AND because I have provided
> > > a solid and sound argument why, in the Theory and Processes Help
> >
> > > Files available at http://www.ciphile.com
> >
> > No, you have not provided a "solid and sound argument why" what you have provided
>is a very,
> > very complex algorithim that does in many steps what most algorithims do in a few,
>and still
> > have not explained how with the artifact laden Mix files one may generate clean
>OTPs.
> >
> > >
> > >
> > > There is no more bias in the OTPs from OAP-L3 than there are from
> > > picking true random numbers since the recommended use requires
> > > that the user input true random numbers when choosing what
> > > processes to run and what input parameters to use in each process.
> > > True random numbers in: true random numbers out. This should be
> > > a no brainer.
> >
> > Really? Your logic is flawed at at least two points
> >
> > 1) People are lousy pickers of "true random numbers" -- we tend to pick favorites,
>and to
> > avoid certian patterns and select other "more random looking ones" -- hand
>generated OTPs
> > were an insecure point in many early code departments.
> >
> > 2)A simple example of the falehood of random numbers in, random numbers out. - If
>I write a
> > program and ask for a random number, and whatever I do my program outputs the
>number 4867,
> > then what I have is "random numbers in, single number out" -- while I do not claim
>that your
> > program is flawed in any similar manner, just because I imput some random numbers,
>and do some
> > calculations based on them all it means is that my program is at MOST as random as
>its inputs,
> > and in many cases it means that my program is less random than its inputs.
> >
> > >
> > >
> > > I have supported everything I have said here in this news group
> > > and in the Help Files available at my web site. None of you have
> > > supported anything you have said.
> >
> > Your RNG ( used to generate your mix files) has a definite and obvious flaw that
>should be
> > visible to anyone who has ever taken a serious look at it. There are points where
>the 10
> > digit permutation("scramble" may be easily masked out of the generated data, and
>given since
> > that is no longer there, attacks versus the "Mix", "redistribute" and "scramble"
>are easily
> > available. If you do not know of what I speak, ask, and I will gladly provide
>further more
> > information. True this is a minor flaw( one of many), and as you have setup your
>code data
> > under it is reasonably secure, but if 5 minutes of analisys of your mix file
>generation gives
> > this, what other flaws lurk? Let me say this now "your algorithim is secure-- at
>least versus
> > me", but I do not feel that the level of security it gives is close to that of
>much easier to
> > use programs, nor do I feel that it provides any premium in any way versus
>existing free
> > software such as PGP.
> >
> > >
> > >
> > > Mr. Huuskonen claims that the current implementation of the random
> > > digit generator is not cryptologically sound.
> >
> > True.
> >
> > > Have any of you
> > > asked Mr. Huuskonen if the output from the random digit generator
> > > is used to encrypt messages?
> >
> > No it is not, at leas not directly. It is not used to encode in the same way that
>in a car
> > with power steering, turning the steering wheel does not actually move the wheels,
>it moves
> > something which in turn makes something else move the wheels. -- the RNG is used
>to make
> > things that are processed to make other things, that are combined with other
>things, which
> > eventually after many steps, produces the output.
> >
> > > No, none of you have. This is
> > > because none of you knows what they are talking about.
> >
> > We aren't the only people in this discussion that don't seem to know what they are
>talking
> > about.
> >
> > >
> > >
> > > The output from the random digit generator is not used to encrypt
> > > messages in OAP-L3.
> >
> > Semi-true
> >
> > > And there is no way Mr. Huuskonen or anyone
> > > else is going to get the extensive secret data required to attempt
> > > an analysis as he has proposed.
> >
> > Probably true, unless OAP-L3 goes into general use.
> >
> > > If one could, they would also have
> > > access to the key and or the OTPs themselves, and would not waste
> > > the time attempting such an analysis.
> >
> > Umm, real breaks of real cyphers are generally done by testing and eliminating
>possible
> > guesses -- this analisys is precisely the sort that would be done to aquire such
>data.
> >
> > > So the idea that the random
> > > digit generator is not cryptologically sound is a statement with no
> > > implications to the security of OAP-L3 software as currently
> > > implemented.
> >
> > Try "minimal" unless, of course, it is actually used to encrypt real quantities of
>data.
> >
> > >
> > >
> > > I guess it is like they say in Orange County, California:
> > >
> > > "If you don't get it: you don't get it."
> >
> > And you sir, don't get it.
>
> You insist on knowing what you are talking about. And here I will
> prove you do not: the software says explicitly that it is
> recommended that all user input be true random numbers, etc.,
> and two methods are suggested:
>
> 1) number beans and place them in a bottle and shake them up then
> withdraw them one at a time and this will be your input sequence
>
> 2) use a deck of cards with the two jokers. Add two jokers from
> another deck and label each one with one of the four suits giving
> a deck of 56 cards with 14 cards in each suit with the jack, queen,
> king, joker representing the 11, 12, 13, & 14. Shuffle this deck
> and then peel off one card at a time from the top of the deck and
> place each card in a pile according to suit. You will then have
> four 14 number sequences that can be used for input, etc.
Simply put, such methods were used to hand generate OTPs in the specific example I
gave you. The
problems you will run into is that people will deliberately subvert such processes, or
not shuffle
sulficiently.
In addition I note that you have chosen to respond to only one of the two points I
have raised.
>
>
> Did you not read the Help Files?
>
> Obviously not.
>
> I think you are pathetic to present yourself as a credible poster
> when you clearly do not know what you are talking about.
------------------------------
From: zapzing <[EMAIL PROTECTED]>
Subject: Re: 40-Bit DES Question
Date: Thu, 20 Apr 2000 17:50:30 GMT
In article <[EMAIL PROTECTED]>,
Jim Gillogly <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> >
> > I assume that for 40-Bit DES, known bits are set in the 56 bit DES
key.
> > Can someone tell me which bits are set and to what value? Also,
where
> > is this defined, FIPS?
>
> I hope you're asking so that you can break it, rather than so that you
> can implement it. IBM's responsible for one incarnation of this: look
> up CDMF, for Commercial Data Masking Facility. To their credit, they
> didn't call it encryption. But still... in these days of more relaxed
> export restrictions there isn't even the lame justification that
companies
> used to have for writing emasculated pseudo-crypto.
It really was silly of them, wasn't it?
What would have prevented someone from
producing something like Triple 40-bit DES?
Or would that not have worked well, due
to the nature of the weakening?
It's just a theoretical question, now.
But it could provide some insight into
how they think.
--
Do as thou thinkest best.
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
******************************
