Cryptography-Digest Digest #533, Volume #11 Wed, 12 Apr 00 06:13:00 EDT
Contents:
Re: Miami Herald article about ATM ripoffs ([EMAIL PROTECTED])
Re: SECAN (Diet NSA)
Re: Introductory Crypto Books ("Joseph Ashwood")
Re: Introductory Crypto Books (Paul Rubin)
Re: Massey-Omura protocol & ECC ([EMAIL PROTECTED])
Re: Compaq invents more efficient RSA?! (Scott Contini)
Re: Skipjack algorithm. (David A. Wagner)
Re: General principles of design (Boris Kazak)
O(...) - Newbie question ("ink")
Dense probabilistic encryption (Claudio Di Flumeri)
Re: O(...) - Newbie question ("Joseph Ashwood")
Re: O(...) - Newbie question ("ink")
RE: Q: Inverse of large, sparse boolean matrix, anyone? ("Manuel Pancorbo")
Non-standard shift register sequences ("Al Grant")
MAA Algorithm source and test values (Jorge Davila Muro)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Miami Herald article about ATM ripoffs
Date: Wed, 12 Apr 2000 02:59:57 GMT
In article <8ctu1k$6k5$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Bill Unruh) wrote:
> In <[EMAIL PROTECTED]>
[EMAIL PROTECTED] (Narley Okim) writes:
>
> >Today's Miami Herald has an article by David Green
<[EMAIL PROTECTED]>
> >titled, "S. Florida sees new breed of ATM, credit card crooks". In
> >discussing the magnetic stripes on the backs of credit cards, he
says "Each
> >stripe contains a mathematical logarithm necessary to access that
account."
>
> I suspect he meant algorithm. (just a rearrangement of the first four
> letters). But even that is wrong. It contains an offset to get from
teh
> natural PIN created by encrypting various things like the account
number
> by DES with a secret key to the true pin. (See Ross Anderson's
> explanation many years ago here.)
>
Sometimes, and I stress the word "sometimes", Banks would store the on
the Track II of the stripe information such as the Card number, the
expiry Date and the PIN Offset. The way a PIN Is calculated differs
slightly from bank to bank but most bank will encrypt the card number
with what is knows as the PIN Verification Key (PVK) using DES. The
result ( in 16 Hex Chars ) is then Decimilized using a decimilization
Table. The first x number of chars ( where x is the length of the pin )
is known as the "Natural PIN". A modulo-10 addition with the PIN Offset
will give you the PIN.
Knowing only the PIN Offset and the CArd Number will not give you the
PIN.
More and more banks are storing the PIN Offset ( and the Expiry Date )
on a database on the host computer. This is to allow the customer
facilities such as PIN Change, and so that the bank would not need to
re-issue cards.
The practice of storing the PIN Offset on the card is a relic of the
old days where PIN Verification is done at the ATM and not at the Host.
So I guess there is a high probability that the reporter was clueless.
Hope this helps.
Petang
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Subject: Re: SECAN
From: Diet NSA <[EMAIL PROTECTED]>
Date: Tue, 11 Apr 2000 20:17:03 -0700
In article <
[EMAIL PROTECTED]>,
Pascal Nourry <
[EMAIL PROTECTED]> wrote:
>Hi,
>I am trying to found some information about SECAN security
evaluation in
>NATO context.
>Is someone can help me ?
>Thanks.
>PN
>
>
There is info available starting about a
third of the way down in this document :
http://nra.nacosa.nato.int/pki/hdocs/
pkiahwg10.htm
BTW, if you talk to NATO you can let them
know that, earlier, I figured out a
relationship between the Podkletnov
experiment and their interest in magneto-
hydrodynamics for aerospace purposes.
I toy with Big Brother, yet He does not share His toys with me :-(
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Introductory Crypto Books
Date: Tue, 11 Apr 2000 20:13:50 -0700
Applied Crypto, is a very good start, and you could make due
with just that and a few other references from the web to
update the information to include the status of AES. If you
want to learn as much as possible Counterpane has a huge
downloadable library of paper (over 1300 at last check), and
it should cover just about anything you want to know.
Joe
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: Introductory Crypto Books
Date: 12 Apr 2000 03:34:56 GMT
Josh Tompkins <[EMAIL PROTECTED]> wrote:
>Before I begin, I KNOW that this is a newbie question. Please don't flame me.
No problem with newbie questions. Just don't ask newbie questions
pretending to be an expert, or newbie questions that are constantly discussed
in the newsgroup so you could find the answers by just looking at the past
few days of messages. Your questions are fine.
>I just finished reading "Cryptonomicron" (or however you spell it) by Neal
>Stephenson. The book re-sparked an interest in crypto I've had for a
>while, so now I'm looking for some source material.
>
>I've almost finished reading "The Code Book" by that guy who wrote
>"Fermat's Enigma" (can't remember his name right now), and I've got Applied
>Crypto. What's your opinion on these books?
Applied Crypto is an indispensible programmer's reference.
Fermat's Enigma I thought was pretty good.
The Code Book had interesting stuff, but was a little shallow in my opinion.
>Do you have any other suggestions? I've in a position to purchase books
>right now (as opposed to limiting myself to websites), so any hardcopy
>recommendations?
For historical ciphers (e.g. The Code Book), the classic is David Kahn's
"The Codebreakers" (make sure to get the hardcover edition and not the
paperback which has had all the good parts removed). It doesn't cover
the latest developments (it was written in the 60's) but its coverage
of classical systems is great. Also: Cipher Machines (not sure of
exact title) by Deavours and Kruh.
For technical stuff more thorough than Applied Cryptography, you basically
have to look at conference proceedings, technical papers, etc.
Contemporary Cryptology (ed. Gus Simmons) is a good collection of articles
along these lines.
There are quite a few books about crypto as related to history, that
don't say much about crypto, but are still interesting. For WW2:
The Ultra Secret, by F. W. Winterbotham
Enigma, by Wladislaw Koczaczuk (I always misspell this)
The American Magic, by Thomas Parrish
The Hut 6 story, by Gordon Welchman
are all pretty good. Between Silk and Cyanide, by Leo Marks, is
entertaining but I think it's mostly fiction. The American Black Chamber
by H. O. Yardley is about cryptanalysis in WW1.
For other recommendations, say more about what specific areas you're
interested in and I'll see what I can think of.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Massey-Omura protocol & ECC
Date: Wed, 12 Apr 2000 03:35:14 GMT
In article <[EMAIL PROTECTED]>,
Mike Rosing <[EMAIL PROTECTED]> wrote:
>
> Yeah, I think it might be worth a few hundred bucks to find out if
> it's worth taking risks.
I suppose if MQV is what I eventually want to use I will get in touch
with a pattern attorney. I just don't know any right now. But I think I
would rather use Massey-Omura or Diffie-Hellman, specially since MQV is
no less susceptible to MITM.
For now I've decided to specify Massey-Omura over DH, since it forces
the need to know the Order of the curve. I know that they are saperate
issues but Massey-Omura implies ( not guarantees ) more security.
And Malfor will have to do more work for Massey-Omura MITM attack then
DH.
Thank you very much for your help. Now I have to go read the postings
on Schoffs algol.
Petang
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Scott Contini)
Subject: Re: Compaq invents more efficient RSA?!
Date: 12 Apr 2000 05:16:07 GMT
In article <IXLI4.3670$[EMAIL PROTECTED]>,
Michael Scott <[EMAIL PROTECTED]> wrote:
>Good God they have some nerve patenting the idea.
>
There are a lot of ridiculous patents out there. No doubt
this is another one.
Scott
------------------------------
From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: Skipjack algorithm.
Date: 11 Apr 2000 21:55:24 -0700
In article <[EMAIL PROTECTED]>, CLSV <[EMAIL PROTECTED]> wrote:
> "Douglas A. Gwyn" wrote:
> > The really important thing about Skipjack is the counter.
>
> Yes, that is a really crafty invention.
Well, wait, merely the notion of having a round counter is hardly
novel to Skipjack -- it may be found in the literature far preceeding
the public disclosure of Skipjack. (See, e.g., TEA.)
But I have a suspicion Doug Gwyn might well be suggesting some deeper
properties of the round counter in Skipjack?
------------------------------
From: Boris Kazak <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: General principles of design
Date: Wed, 12 Apr 2000 06:25:03 GMT
Mok-Kong Shen wrote:
>
> John Savard wrote:
> >
>
> > My web site, I hope, may reveal some of these principles to those who
> > study it, even though it mostly illustrates them by examples, instead
> > of stating them.
>
> It would be fine, if you would simply provide some key words,
> so that we could discuss and elaborate.
>
> My goal is to collect a bunch of clearly delineated (fundamental)
> principles that could be useful (though not necessarily used)
> in guiding the design of an encryption algorithm.
>
> M. K. Shen
========================
About a year ago I wrote this just because I wanted to present serious
things in a humoristic way. You please be the judge, is it funny or not,
and can it be useful or not. BTW, it was published in the online
"Journal of Craptology" by Lars Knudsen, he apparently understood the
humor of it. You can find the "Journal" at
<http://www.ii.uib.no/~larsr/crap.html>
***************
... Main question - should the algorithm of the cipher be open for
analysis
or should it be unavailable to cryptanalist? The consensus is that the
algorithm
should be made public, and all the security must be based on the key.
This seems
reasonable, because such requirement closes the door for "snake-oil"
promoters,
whose algorithms cannot be scrutinized.
On the other hand, exact knowledge of the algorithm allows very
finely
tuned attacks, which exploit the minute details of the ciphering
mechanism.
Quoting Schneier: "...chosen-key attack, which exploits the fact that
all rounds
are identical and that the key schedule is just a cyclic shift by 32
bits" (p.327)
"...examined Blowfish with known S-boxes..." (p.339) and so on.
In course of this reading, by an unknown memory twist, I
remembered
a funny word combination - "Problem of a Drunken Sailor". Actually this
is a
serious mathematical problem, conventionally known as the problem of
random walk.
The essense of this problem can be visualized if one imagines a drunken
sailor
on a street crossing in an unknown city. The guy has about the equal
probability
to go in any of the 4 possible directions. On the next crossing there
will be
again 1 out of 4 choice, then again and again, until he comes to the
harbor
(if this ever happens).
And then a crazy idea came to my mind - why not introduce some
trick
which will deny the cryptanalist the access to his main weapon? Why not
make the
algorithm itself key-dependent and plaintext-dependent. In this case our
friend
cryptanalyst will be thrown back to square zero, because there will be
nothing
certain to cryptanalyze - only the "C" code which will explain how the
choices
are made between different algorithms.
Elaborating a little further, the number of possible choices
must be
greater than the combined number of all possible keys and all possible
plaintexts.
Then the brute-force attack will really be the only way - all other ways
will
require more plaintexts or more keys than can exist.
Now the purists are advised to close their eyes and to read the
rest of
the text with the eyes closed, because the main concept which will be
discussed
here is the concept of BOOZE.
BOOZE (orig. boo-zah)
* word of Mongolian origin,
denotes a beverage which
makes
people irrational and
delirious.
* (amer.slang) strong
liquor.
There are two variable parts processed by the encryption
algorithm in
order to produce ciphertext - key and plaintext. Accordingly, if the
choices
in encryption procedure will be dictated by the key alone, we will call
this
Master Booze, if the choices will be dictated by the plaintext, we will
call
this Peer Booze. Both are necessary in varying proportions, and it is my
intent
to draw attention to the fact that a big amount of high quality Peer
Booze is
present in many successful block ciphers. Neglect of the amount or
quality of
Booze (both Master and Peer) facilitates the cryptanalysis enormously.
*****************
Translated into "sci.crypt.speak" this essentially means that I am
for:
1) random key-dependent S-boxes (Master Booze)
2) plaintext-dependent path though these S-boxes (Peer Booze)
Classical example of such a cipher - Blowfish.
Best wishes BNK
------------------------------
From: "ink" <[EMAIL PROTECTED]>
Subject: O(...) - Newbie question
Date: Wed, 12 Apr 2000 09:29:40 +0200
Hello
I've been reading this group for quite a while
and I've been wading through cryptography literature
and papers. I see recurring references to the function
described like O(n^3) or such, but I can't find a
simple explanation of this function. Could anybody
give me a simple hint or a reference to a paper where
this function is described?
Thanks in advance, and keep up the good work, this
is a great newsgroup!
Regards
Kurt In Albon
------------------------------
From: Claudio Di Flumeri <[EMAIL PROTECTED]>
Subject: Dense probabilistic encryption
Date: Wed, 12 Apr 2000 09:47:37 +0200
Reply-To: [EMAIL PROTECTED]
Hi,
Have you read the paper "Dense probabilistic encryption" by Josh
Benaloh?
If you done it, can you explain me how the certificate u is used to
prove that an encryption z is an encryption of a message M?
Thanks in advance,
CDF
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: O(...) - Newbie question
Date: Wed, 12 Apr 2000 01:29:11 -0700
Very simply. Express the instructions needed to perform the
computation in terms of the length of the input, select the
dominant factor for very large sizes and put it inside O().
In a very small nutshell that is it, a typical example is
bubble sort, which looks like:
for i = 1 to n
for j = i to n
if array[i] > array[j]
swap(array[i], array[j])
endif
end for j
end for i
it doesn't take much work to determine that it takes
approximately the square of the length of array
instructions, thus bubble sort is an O(n^2) algorithm. It is
typically much more difficult to solve, and can be
astoundingly complex like the time of factoring algorithms
which tend to have excessively complex timing
characteristics.
Joe
"ink" <[EMAIL PROTECTED]> wrote in message
news:8d18ju$3u9$[EMAIL PROTECTED]...
> Hello
>
> I've been reading this group for quite a while
> and I've been wading through cryptography literature
> and papers. I see recurring references to the function
> described like O(n^3) or such, but I can't find a
> simple explanation of this function. Could anybody
> give me a simple hint or a reference to a paper where
> this function is described?
>
> Thanks in advance, and keep up the good work, this
> is a great newsgroup!
>
> Regards
> Kurt In Albon
>
>
>
------------------------------
From: "ink" <[EMAIL PROTECTED]>
Subject: Re: O(...) - Newbie question
Date: Wed, 12 Apr 2000 10:50:12 +0200
Joseph Ashwood <[EMAIL PROTECTED]> schrieb in im Newsbeitrag:
OnpATlFp$[EMAIL PROTECTED]
> Very simply. Express the instructions needed to perform the
> computation in terms of the length of the input, select the
> dominant factor for very large sizes and put it inside O().
> In a very small nutshell that is it, a typical example is
> bubble sort, which looks like:
<snip>
Thanks a lot, Joe, and all the guys who replied off ng.
You're a helpful bunch!
Kurt
------------------------------
From: "Manuel Pancorbo" <[EMAIL PROTECTED]>
Subject: RE: Q: Inverse of large, sparse boolean matrix, anyone?
Date: Wed, 12 Apr 2000 10:53:29 +0200
Mok-Kong Shen :
> Gadi Guy wrote:
> >
> >
> > My algorithm fails miserably most of the time, which lead me to
> > believe that maybe there's something more to inverting boolean
> > matrices than they teach in numerical analysis.
>
> Perhaps I am over cautious. But I do want to avoid a probable
> language ambiguity. A Boolean matrix is not identical to (though
> has the same form as) an integer matrix whose elements are either
> 0 and 1. One uses Boolean arithmetics, e.g. 1 + 1 = 0. A normal
> library Gaussian elimination subroutine, such as the one in
> Numerical Recipes, is hence not applicable to a Boolean matrix.
>
Why not? all you have to do is apply the given recipes but modulo 2. It is
the same boolean matrices and 'modulo 2' matrices.
I'm designing a cipher algorithm based on matrix algebra modulo 2. Make sure
that I had no problem with the usual numerical recipes for handing matrices;
simply, I apply them 'modulo 2'.
--
+ Manuel Pancorbo
+ [EMAIL PROTECTED]
+ "...
+ M�s vale aprender una sola l�nea de Ciencia
+ que postrarse cien veces en oraci�n. (Cor�n)
+
+ Pli valoras lerni ech nur unu linion de Scienco
+ ol preghe genui cent fojojn. (Korano)
+ ..."
------------------------------
From: "Al Grant" <[EMAIL PROTECTED]>
Subject: Non-standard shift register sequences
Date: Wed, 12 Apr 2000 10:10:31 +0100
I'm looking for literature on two non-standard shift-register
techniques:
1. use of a value computed from previous outputs, e.g.
A_i = A_{i-n} + sum(A_0 to A_{i-1})
where the sum is computed by updating an accumulator
with each new output
2. variable taps, e.g.
A_i = A_{i-n} + A_{i-f(S)}
where f(S) is some function on the current register contents,
and/or using an additional state value as described above.
It may of course be possible to reduce either of the above
to a normal recurrence, maybe even a linear recurrence,
in a particular case. I'm particularly interested in proposals
or real-world deployed examples which have been shown
to be weak.
------------------------------
From: Jorge Davila Muro <[EMAIL PROTECTED]>
Subject: MAA Algorithm source and test values
Date: Wed, 12 Apr 2000 11:20:20 +0200
This is a multi-part message in MIME format.
==============208E4DE5A26EFD8C84288529
Content-Type: multipart/alternative;
boundary="------------B2C99225669FF892DA6A0988"
==============B2C99225669FF892DA6A0988
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Hello,
I don't know if someone in sci.crypt could help me. I�m looking for
detailed technical information about the MAA (Message Authenticator
Algorithm) published by Davies in 1983 and adopted by ISO as a Banking
standard. I would like to have that algorithm in source code and some
good tests values. Thanks in advance for your help.
- Jorge D�vila -
PS: Please direct your answers also to my e_mail address
[EMAIL PROTECTED] (sometimes sci.crypt is unreachable for me and I
wouldn't like to miss your answers)
==============B2C99225669FF892DA6A0988
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<br>Hello,
<p>I don't know if someone in sci.crypt could help me. I´m
looking for detailed technical information about the MAA (Message Authenticator
Algorithm) published by Davies in 1983 and adopted by ISO as a Banking
standard. I would like to have that algorithm in source code and some good
tests values. Thanks in advance for your help.
<p>- Jorge Dávila -
<p>PS: Please direct your answers also to my e_mail address <a
href="mailto:[EMAIL PROTECTED]">[EMAIL PROTECTED]</a>
(sometimes sci.crypt is unreachable for me and I wouldn't like to miss
your answers)</html>
==============B2C99225669FF892DA6A0988==
==============208E4DE5A26EFD8C84288529
Content-Type: text/x-vcard; charset=us-ascii;
name="jdavila.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Jorge Davila Muro
Content-Disposition: attachment;
filename="jdavila.vcf"
begin:vcard
n:Davila Muro;Jorge
tel;fax:34 91 336 69 42
tel;work:LSIIS - Facultad de Inform�tica - UPM
x-mozilla-html:TRUE
url:tirnanog.ls.fi.upm.es
org:Universidad Polit�cnica de Madrid;LSIIS - Facultad de Inform�tica
adr:;;Campus de Montegancedo s/n;Madrid;Madrid;28660;Espa�a
version:2.1
email;internet:[EMAIL PROTECTED]
title:Profesor Titular
fn:Jorge D�vila
end:vcard
==============208E4DE5A26EFD8C84288529==
------------------------------
** 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
******************************
