Cryptography-Digest Digest #270, Volume #11 Tue, 7 Mar 00 02:13:01 EST
Contents:
Re: avoid man-in-the-middle known plaintext attack using a stream cipher (David
Hopwood)
Re: avoid man-in-the-middle known plaintext attack using a stream cipher (David
Hopwood)
Re: sci.crypt Cipher Contest (Nicol So)
FTP for research (Tom St Denis)
Re: ascii to binary (John Wingate)
Re: sci.crypt Cipher Contest ("Adam Durana")
Re: ascii to binary (Anne & Lynn Wheeler)
Re: differential cryptanalysis ("Douglas A. Gwyn")
Re: math error? NOT AT ALL ... ("Douglas A. Gwyn")
Re: Cellular automata based public key cryptography ("Douglas A. Gwyn")
Re: very tiny algorithm - any better than XOR? (Paul Rubin)
Re: very tiny algorithm - any better than XOR? (Paul Rubin)
Re: ascii to binary (Anne & Lynn Wheeler)
Re: why xor?(look out,newbie question! :) (John Savard)
----------------------------------------------------------------------------
Date: Tue, 07 Mar 2000 03:28:11 +0000
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: avoid man-in-the-middle known plaintext attack using a stream cipher
=====BEGIN PGP SIGNED MESSAGE=====
Adam Back wrote:
> David Hopwood wrote:
> > The most obvious, and a robust way of doing this is to append a MAC,
> > with an output length of n bits. In principle it might be possible to
> > combine the authentication with the encryption for performance reasons,
> > but previous attempts at doing that (e.g. PCBC, iaPCBC, CBCC) have
> > not been resounding successes from a security point of view.
>
> What is iaPCBC? or is this a typo?
iaPCBC is "integrity aware Propagating Cipher Block Chaining", by
Virgil Gligor and Pompiliu Donescu, as described in [1] and [2].
It was broken by David Wagner et al at Counterpane in [3] (despite
a "proof of security"). There was also a thread about it in sci.crypt [4].
(Gligor and Donescu have proposed a modification to their scheme [5] to
attempt to fix this attack, but I'm not convinced that the modification
is sufficient, and it doesn't appear to address the flaws in the security
proof.)
Incidentally, an attack on the use of PCBC for authentication in Kerberos
version 4 is documented in [6], and an attack on CBCC in [7].
[1] Virgil D. Gligor <[EMAIL PROTECTED]>,
Pompiliu Donescu <[EMAIL PROTECTED]>,
"Integrity-Aware PCBC Encryption Schemes,"
http://www.research.att.com/~smb/papers/iapcbc.ps
November 11, 1999.
[An earlier version was presented at the 7th International Workshop
on Security Protocols, Cambridge, U.K., April 1999. An abridged
version will appear in "Security Protocols", LNCS, Springer-Verlag,
B. Christianson, B. Crispo, M. Roe (eds.)]
[2] Virgil D. Gligor, Steven M. Bellovin,
"An iaPCBC Transform for IPsec,"
http://www.research.att.com/~smb/papers/draft-bellovin-iapcbc-00.txt
(IETF draft; work in progress, expires May 2000.)
[3] Niels Ferguson, Doug Whiting, John Kelsey, David Wagner,
"Critical Weaknesses of iaPCBC,"
November 24, 1999.
Possibly at www.counterpane.com; if not then ask the authors.
[4] Go to www.deja.com, and search in sci.crypt for a subject field
containing iaPCBC.
[5] Virgil D. Gligor,
Private email to me and to the authors of [2].
(I don't know whether this proposed fix has been published.)
[6] John T. Kohl,
"The Use of Encryption in Kerberos for Network Authentication,"
Advances in Cryptology - CRYPTO '89 Proceedings,
Springer-Verlag, 1990, pp. 35-43.
[7] A. Menezes, P. C. van Oorschot, S. A. Vanstone,
"Example 9.89 (CBC encryption with XOR checksum - CBCC),"
Handbook of Applied Cryptography, CRC Press, 1997.
http://www.cacr.math.uwaterloo.ca/hac/about/chap9.pdf, .ps
- --
David Hopwood <[EMAIL PROTECTED]>
PGP public key: http://www.users.zetnet.co.uk/hopwood/public.asc
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOMR3NDkCAxeYt5gVAQEbOQgAqf1GEmYTTgGZgMt8QHLYqaaV/KiPR9Ih
/QbyDeZLfdCkN6EfLrLnxOp0ZdU7RQOa/VyOrisaHgRGU52hWY2abLeqaoNZpxwY
eV2GSGLWB3TLSlI5z29BdcQStPg+iyWXH81a1ZY1puzUi4UKT9nhfVXRVcQKmF/h
zv+0+luJxknpViWdgefbY9Qs9BAFGgg+Y5RE2430Tnv+BZwf1Ldumtb7jpEYeZJo
oWQFOLEem2RMP5xhigQhqHuwkQWhMuhdjFFP1BGV1bQgly0192RDDeUn64BiE8aZ
x5S+J8Tfi2YDaSv1kLXRUH221K/g1E6xVmt8VljDJJMyNRgv11YXqg==
=RSW2
=====END PGP SIGNATURE=====
------------------------------
Date: Tue, 07 Mar 2000 03:29:54 +0000
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: avoid man-in-the-middle known plaintext attack using a stream cipher
=====BEGIN PGP SIGNED MESSAGE=====
[EMAIL PROTECTED] wrote:
> In a previous article, David Hopwood <[EMAIL PROTECTED]> writes:
> > I can think of two possibilities for a CFB-like mode with plaintext
> > feedback.
>
> This is what I meant. [...]
> S[I]: Ith byte of an OTP,
I'm not sure why you would want to use a scheme based on a conventional
cipher, when an OTP is available. In situations where it is feasible to
use an OTP, there are provably information-theoretically-secure mechanisms
that can be used to ensure integrity (for example based on universal
hashing).
- --
David Hopwood <[EMAIL PROTECTED]>
PGP public key: http://www.users.zetnet.co.uk/hopwood/public.asc
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOMR3jDkCAxeYt5gVAQE4mAgAwdEvAcq6sk8rQnuflCUoxsTdAma9HAhd
9MDy3Kwz5wmLJguZ0vQy1V5fabJPWu3QhNLQe6AbI6Kq4Mc5QaaQJGMIfkQ8g7Q4
2aQBHSjBFF9BXJsnfxK1B/juAoLrYVpigIzhR0KI7LzbdtfGu753tJuNQHg1HxIj
LVEkPii8mxUwoh7gEurg9ux3yHjT+vpNK3ItxiS3z+JEvvGqi0FWRHarbMI7OsF/
s5rp/e3vphe6K48wFCPl+Tf6yQBEdrHprcgXx60vivQXR2ug6v0XrVTIXwNyFzy1
1sjlJIESHns7lN72nQr9iPAAbcEUY/w4+evGOc7Mk1l/y7MPFZJmGA==
=//XU
=====END PGP SIGNATURE=====
------------------------------
From: Nicol So <[EMAIL PROTECTED]>
Subject: Re: sci.crypt Cipher Contest
Date: Mon, 06 Mar 2000 22:45:48 -0500
Reply-To: see.signature
Adam Durana wrote:
>
> I see a lot of ideas for encryption algorithms posted to sci.crypt all the
> time, and I know several regular posters have thier own ciphers they have
> developed. Since most of us are amateur cryptographers, and study
> cryptography for fun. I thought it might be fun to have a contest such as
> AES. And at the end we could select the best cipher based on the criteria
> we decide on. ...
A few random thoughts. If you're doing it for fun or to learn more about
ciphers, it is not necessary to have a contest. It'll be fun and
educational just to have a group of hobbyists designing practice ciphers
and breaking one anothers' designs. Since ciphers are used to protect
the privacy and/or integrity of data, it is not very meaningful to judge
them by arbitrary criteria--whatever criteria you use should have some
(perferably demonstrable) connection to security.
> The only thing I can think of right now that should be in the criteria is
> that an entry should be a block cipher. Ofcourse other details such as key
> size, block size and etc will need to be decided on.
I don't see any good reason to restrict yourselves to only block
ciphers. The parameters you mentioned are, in my opinion, rather
unimportant, especially when you're not using the designs to protect
anything of value. I would suggest the following requirement on the
ciphers:
"Any cipher put forth should demonstrate some novel design principle(s).
The designer should have at least a plausible argument why the design
principle(s) would make the cipher secure. Merely stating the equivalent
of "I can't see how anyone can break it" is not considered sufficient."
--
Nicol So, CISSP // paranoid 'at' engineer 'dot' com
Disclaimer: Views expressed here are casual comments and should
not be relied upon as the basis for decisions of consequence.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Crossposted-To: comp.compression,sci.math
Subject: FTP for research
Date: Tue, 07 Mar 2000 04:03:36 GMT
If you want to share files with the science comunity and don't quite
have a place for them, while my comp is in running order I will offer
my ftp site at
ftp://24.42.86.123
l/p = sci/sci
I set aside 50MB of space for it.
Tom
--
[EMAIL PROTECTED]
BTW my offer for personal research space is still valid. If you want
an ftp/http account at my website just ask.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: John Wingate <[EMAIL PROTECTED]>
Subject: Re: ascii to binary
Date: Tue, 07 Mar 2000 04:27:08 GMT
wtshaw <[EMAIL PROTECTED]> wrote:
> In article <8a0rme$q1s$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
> (Vernon Schryver) wrote:
>>
>> Didn't cards have 12 rows and 80 columns for decades before the 96-column
>> cards arrived in the 1970's? Weren't the twelve holes on the classic
>> punched cards labeled 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, + and - (at least
>> by how you would punch individual holes to generate non-standard
>> combinations).
> I saved some of the blanks when I disposed of the boxes and boxes of cards
> long ago. In fact a couple are under my desk top. No, just ten rows and
> eighty columns. Punching too many holes tended to cause the cards to
> self-distruct.
I have a stack of blank cards too. (They make good bookmarks.) Only
10 rows are labeled, but 12 rows were used for punching. CDC binary
files were punched with each 60-bit word taking up five columns--
16 words per card.
--
John Wingate If there is a God he must have
[EMAIL PROTECTED] an odd sense of humour.
--- Chaim Bermant
------------------------------
From: "Adam Durana" <[EMAIL PROTECTED]>
Subject: Re: sci.crypt Cipher Contest
Date: Tue, 7 Mar 2000 00:39:54 -0500
> A few random thoughts. If you're doing it for fun or to learn more about
> ciphers, it is not necessary to have a contest. It'll be fun and
> educational just to have a group of hobbyists designing practice ciphers
> and breaking one anothers' designs. Since ciphers are used to protect
> the privacy and/or integrity of data, it is not very meaningful to judge
> them by arbitrary criteria--whatever criteria you use should have some
> (perferably demonstrable) connection to security.
> I don't see any good reason to restrict yourselves to only block
> ciphers. The parameters you mentioned are, in my opinion, rather
> unimportant, especially when you're not using the designs to protect
> anything of value. I would suggest the following requirement on the
> ciphers:
> "Any cipher put forth should demonstrate some novel design principle(s).
> The designer should have at least a plausible argument why the design
> principle(s) would make the cipher secure. Merely stating the equivalent
> of "I can't see how anyone can break it" is not considered sufficient."
I thought by having a contest more people would be interested. I think
people would be more likely to give some real thought to breaking some
else's cipher if they are in direct competition with that person. A
competition would also give people a chance to "prove" themselves. Someone
who participated could show that they can apply their knowledge of
cryptology by designing a good cipher and/or breaking ciphers others have
designed. It would give those people who have nothing better to do than
flame postings for typos and other such things something to do. =) And if
its going to be a contest there needs to be a set of requirements for the
candidates, or it will be impossible to judge them. I suppose it might be
worth having different levels to the contest, such as beginner, intermediate
and expert, since obviously someone just starting to study cryptography
won't be able to compete with people who have been studying it for years.
This all assuming people actually want to participate and it does not seem
like many want too.
I figure the lay out of the whole contest would be something like this
- Decide on requirements for candidate ciphers and rules of the contest.
- A few weeks for people to design and analyze their entries.
- Deadline for entries.
- Contest begins
- A few weeks for analysis of candidates (Round 1)
- Candidate ciphers who met all the requirements (and were not broken) would
move on to Round 2
- Round 2 would be a few weeks
- After round 2 if a round 3 was needed we could have one, if not then we
could decide on the best cipher and select it as the winner.
- Contest ends when the winner is selected.
So if you are interested in taking part, make a post, send me an email, etc.
There are no rules as of yet, so pretty much anything is possible, you can
form teams, submit multiple ciphers, etc etc etc.
- Adam
------------------------------
Subject: Re: ascii to binary
Reply-To: Anne & Lynn Wheeler <[EMAIL PROTECTED]>
From: Anne & Lynn Wheeler <[EMAIL PROTECTED]>
Date: Tue, 07 Mar 2000 06:01:07 GMT
John Wingate <[EMAIL PROTECTED]> writes:
> I have a stack of blank cards too. (They make good bookmarks.) Only
> 10 rows are labeled, but 12 rows were used for punching. CDC binary
> files were punched with each 60-bit word taking up five columns--
> 16 words per card.
discussed sporadically on alt.folklore.computers.
709/709x/1401/etc binary could have all 12x80 holes punched & used BCD
for character codes. with 360s & ebcdic (a superset of bcd)
... allowed for 256 codes (8bit bytes, four? holes per column was the
most used & would generate hardware errors for columns with invalid
hole combinations, my green card is in storage).
360s could interface to card reader/punch using something called
column binary for processing 709/709x/1401/etc binary cards using
160bytes ... effectively each column had pairs of 6bit codes mapped to
pairs of 360 (8bit) bytes
table that use to give punch codes:
http://www.s390.ibm.com:80/bookmgr-cgi/bookmgr.cmd/BOOKS/DZ9AR004/I%2e0
random reference:
http://users.ticnet.com/davea/greencard/start.htm
http://www.cwi.nl/people/dik/english/codes/80col.html
http://tronweb.super-nova.co.jp/characcodehist.html
http://www.fourmilab.ch/documents/univac/fieldata.html
--
Anne & Lynn Wheeler | [EMAIL PROTECTED], [EMAIL PROTECTED]
http://www.garlic.com/~lynn/ http://www.adcomsys.net/lynn/
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: differential cryptanalysis
Date: Tue, 07 Mar 2000 06:38:08 GMT
[EMAIL PROTECTED] wrote:
> The most appropriate symbol for xor would be a "V" with a cross
> stroke. That's how the boolean operator is denoted in formal logic.
Except when some other symbol is used.
(Most of us use "+" and establish that the context is GF(2).)
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Crossposted-To: comp.security.misc,alt.security.pgp
Subject: Re: math error? NOT AT ALL ...
Date: Tue, 07 Mar 2000 06:39:26 GMT
Xcott Craver wrote:
> >Anton Stiglic wrote:
> >> I can't explain you that here, you need any descent calculus book
> >> for that.
> Not that nCr or nPr have anything to do with this computation.
Nor does calculus.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Cellular automata based public key cryptography
Date: Tue, 07 Mar 2000 06:44:46 GMT
[EMAIL PROTECTED] wrote:
> [A side question- Earlier, was the Garden of Eden problem (deriving the
> starting pattern from an n-th iteration) the main obstacle to
> implementing CA based cryptosystems, especially given the fact that some
> CAs don't have a single inverse because of multiple inputs going into
> the same output?]
I think the main obstacle was certainly its lack of reversibility.
That pretty much limits one to using it as a KG, and there are
better cryptosystems than that.
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: very tiny algorithm - any better than XOR?
Date: 7 Mar 2000 06:48:00 GMT
In article <89sm5g$826$[EMAIL PROTECTED]>,
Carl Byington <[EMAIL PROTECTED]> wrote:
>I will ask about this. I would be more than happy to have someone that
>knows what they are doing help with this. When this project started,
>everyone assumed we had enough code space to do TEA. The failure of that
>assumption has pushed me into trying to design a moderately secure but
>very tiny algorithm, which is clearly outside the boundaries of my area
>of competence.
It seems to me that rather than obsessing about fitting the cipher into
50 bytes, you can probably spend the time bumming a few dozen more
bytes out of the rest of the code, especially if it's written in C
and you can tweak the compiler output.
The other thing (I said this before but had made a typo in it) is that
unless you have seriously tamper resistant hardware (which you don't),
cryptanalysis isn't going to be too big an issue. If I were attacking
your system and didn't see within about 5 minutes how to break the
cipher, I'd move on to a hardware attack. If there are any off-chip
wires where unencrypted data goes in your circuit, you have no
security at all no matter what encryption you use. Even if all the
secrets never leave the chip, if your content is really valuable then
you're still fairly open to attackers with serious lab equipment.
Cable TV pirates do that kind of stuff all the time. So I wouldn't
spend that much time obsessing about the cryptography in a system like
this. I'm assuming you're making some kind of high-volume consumer
gadget or else you wouldn't be talking about such cheap parts. So
it's almost certain that attackers will be able to get some to take apart.
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: very tiny algorithm - any better than XOR?
Date: 7 Mar 2000 06:49:01 GMT
In article <89uk10$50b$[EMAIL PROTECTED]>,
Carl Byington <[EMAIL PROTECTED]> wrote:
>Can we use the 16 byte key itself as SBOX[16], and then
>
>v[i] = v[i+1] ^ k[(t + k[r*4+j] + i) & 0xf];
You really want much more S-box material if you can manage it.
------------------------------
Crossposted-To: alt.folklore.computers
Subject: Re: ascii to binary
Reply-To: Anne & Lynn Wheeler <[EMAIL PROTECTED]>
From: Anne & Lynn Wheeler <[EMAIL PROTECTED]>
Date: Tue, 07 Mar 2000 06:53:35 GMT
... oops, a little too quick on the send.
url with complete bcd & ebcdic card codes (26key punch, 29key punch)
http://www.cs.uiowa.edu/~jones/cards/codes.html
it also has proprietary 026 varients by control data, dec, GE, &
univac
--
Anne & Lynn Wheeler | [EMAIL PROTECTED], [EMAIL PROTECTED]
http://www.garlic.com/~lynn/ http://www.adcomsys.net/lynn/
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: why xor?(look out,newbie question! :)
Date: Tue, 07 Mar 2000 06:39:46 GMT
On Mon, 6 Mar 2000 17:26:16 -0000, "Joseph Ashwood"
<[EMAIL PROTECTED]> wrote, in part:
>> I thought that were already the past. Which are the
>typical
>> manufacturers of the two different groups today?
>x86 and everyone else. Actually that's not quite true, most
>new processor designs support both directions, but the OS
>chooses one or the other.
While I'd like to support that point of view, I remember reading an
article that painted the picture the other way: those wanting to put
numbers in memory were called the "outlaws", and the article noted
that they often worked their mischief in floating-point units.
The Power PC chip and the forthcoming Itanium chip from Intel are
examples of processors that support both directions.
In the past, the order resembling how numbers are written in English
and in other European languages, the most significant part coming
earlier in the low address, was used by the IBM 360 and later by the
Motorola 68000. (In this order, the hex number 12345678 would be
stored as the bytes 12 34 56 78.)
The opposite order - suitable to Arabic, since it is read from right
to left, yet the least significant digit is still on the right - was
used by the PDP-11, the MOS Technology 6502, and the Intel 8080 and
8086 to Pentium. Also, the National Semiconductor 16032. (In this
order, the hex number 12345678 would be stored as 78 56 34 12.)
Some older minicomputers used the order 56 78 12 34, because they
stored numbers 16 bits at a time, and stored a 16-bit number in
conventional order, but then stored 32-bit numbers so that the last
half was first for faster adding. (The Honeywell 316, a computer used
for Internet communication purposes in the earliest days, was one of
these, IIRC.)
To me, the IBM 360 order is simply easier to understand. But others,
seeing IBM as a menacing monolith, seeing the PDP-11 as the computer
of liberation, UNIX, and C, and finding it simpler that bit 0 of a
word always represents the value of 2^0, champion the other order,
and, except at Motorola and Texas Instruments, they carried the day in
most of the world of microcomputer chips.
------------------------------
** 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
******************************
