Cryptography-Digest Digest #998, Volume #10 Sat, 29 Jan 00 01:13:02 EST
Contents:
Re: Pencil & paper cipher question ("r.e.s.")
Re: can someone encrypt for me? (HeuyWorld)
Re: Pencil & paper cipher question ("r.e.s.")
Re: Pencil & paper cipher question (David Wagner)
Re: Crypto/Security/Cryptanalysis Papers (Tom St Denis)
Block chaining ("Adam Durana")
Re: Intel 810 chipset Random Number Generator ("Trevor Jackson, III")
Re: "Trusted" CA - Oxymoron? (John G. Otto)
Re: How to password protect files on distribution CD (Johnny Bravo)
Re: Block chaining (David Wagner)
Re: *** ECC Strong and Weak combined (David Hopwood)
Re: ECM Factoring and RSA Speed Ups (David Hopwood)
Re: How much does it cost to share knowledge? ("Douglas A. Gwyn")
Re: Mac encryption algorithm? ("Douglas A. Gwyn")
Re: How much does it cost to share knowledge? (David A Molnar)
Re: Classical Crypto Books ("Douglas A. Gwyn")
Re: NEC claims New Strongest Crypto Algor (wtshaw)
Re: "Trusted" CA - Oxymoron? (wtshaw)
----------------------------------------------------------------------------
From: "r.e.s." <[EMAIL PROTECTED]>
Subject: Re: Pencil & paper cipher question
Date: Fri, 28 Jan 2000 18:50:50 -0800
[ apologies if this posting appears twice -- my server's misbehavin' ]
"Uri Blumenthal" <[EMAIL PROTECTED]> wrote ...
: John Savard wrote:
[...]
: > The use of a straddling checkerboard, so that you can add digits
: > instead of using a 26 x 26 Vigenere table is then advisable.
: >
: > You might get some ideas from my page. I'd recommend something
: > involving fractionation. <http://www.ecn.ab.ca/~jsavard/crypto.htm>
:
: Yes, a very good advice. My vote goes for VIC. It's bloody hard
: to memorize the generation sequence, but once it's done, it's
: quite secure.
It was quite secure before the algorithm became well-known, but if
an opponent knows that VIC is the cipher you're using, then the
effective keyspace entropy is no more than ~36 bits. (I'm referring
to the VIC cipher as described on John Savard's website, mentioned
above.)
The VIC cipher uses a "passphrase" of 6 digits and 20 letters, but
processes it down to a critical string of 10 digits (i.e. 33 bits),
and this string completely specifies both a straddling checkerboard
and a double transposition, assuming the algorithm is known. Even
if we add another 3.3 bits for the one digit used to hide the
message key, that's still only ~36 bits.
So it seems to me that to be reasonably secure, the VIC cipher
needs to be modified, say to lengthen its "critical digit string"
to ~20 digits, for ~66 bits of entropy. (And correspondingly longer
passphrases should then be incorporated.)
But as for the main crypto components (the straddling checkerboard
& double transposition) -- they represent well over 100 bits of
entropy to a brute-force attack. In fact, the checkerboard (even
assuming it's built around a known permutation of the alphabet)
has at least 10! keys -- 22 bits -- and the double transposition
with variable column widths has a number of keys equal to
sum(m!n!, m=lo..hi, n=lo..hi, m=/=n). With lo=11 and hi=20,
corresponding to VIC having a "personal id#" of 10, the latter
amount is ~119 bits. (A pid# of 8 would give ~102 bits.) If we
include the single digit used to hide the message key (3.3 bits),
this means the total entropy *potential* of the cipher is at least
~134 bits against a brute-force attack. But to take advantage of
that potential, these components would need to be "packaged" more
securely than in the published version.
(I wish I had a better idea of the difficulty of "breaking" the
sort of double transposition involved here -- it's esp. difficult
because although the first stage transposition uses a simple keyed
row-wise fill, the second one uses a keyed "serrated fill".
Considering also that the column widths are random, and that the
symbols are fractionated digits with a quite uniform frequency
distribution, it's hard to believe that this could be anywhere
close to breakable in practice, if properly "packaged" as
described above.)
--
r.e.s.
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (HeuyWorld)
Subject: Re: can someone encrypt for me?
Date: 29 Jan 2000 03:04:12 GMT
>Subject: can someone encrypt for me?
>From: [EMAIL PROTECTED] (Cutedoggy99)
>Date: 1/16/00 3:48 AM Eastern Standard Time
>Message-id: <[EMAIL PROTECTED]>
>
>Could someone please encrypt this url address for me in crypto version 0:
>
>http://www.cutedoggy.com/sponsors/
>
>
>
here it is in DDEZI .. hope this clears things up ... :
02106106133133715715701101101114704117106107121115132132126114704115137115
7001331151141001151351001157
------------------------------
From: "r.e.s." <[EMAIL PROTECTED]>
Subject: Re: Pencil & paper cipher question
Date: Fri, 28 Jan 2000 19:03:46 -0800
"David Wagner" wrote ...
: Ok, so let's assume for the moment that the initial fill of the
: "shift register" with digits can be made sufficiently secure (hard to
guess).
:
: That may rule out exhaustive keysearch attacks, but how do you know there
: are aren't clever attacks that treat VIC as a LFSR with nonlinear output?
: There's been a lot of progress in the open literature on cracking such
ciphers
: (e.g., correlation attacks).
:
: Moreover, we may expect that the military is even better at cracking
: LFSR-based ciphers than the academic community is, because it is rumored
: that most military ciphers are (or were) shift-register based.
:
: Do these observations shake confidence in VIC?
(Unfortunately my own postings are not appearing as usual on my server,
and since you didn't quote any text, I can't tell whose posting you're
replying to.)
It seems to me that the VIC cipher uses so few digits (50 per message)
generated by LSFR with non-linear read-out, that this would not be a
practical entry. But who knows?
As I explained in a previous posting, I think the obvious weakness of
the cipher as published, is that it uses one "critical string" of 10
digits to determine both the straddling checkerboard and the double
transposition. That may not have been a problem when the cipher itself
was secret, but surely it's a problem now. (But it's easily fixed,
I think.)
--
r.e.s.
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: Pencil & paper cipher question
Date: 28 Jan 2000 19:20:21 -0800
In article <86tk75$jni$[EMAIL PROTECTED]>,
r.e.s. <[EMAIL PROTECTED]> wrote:
> "It is interesting to note that, regardless of how inconvenient
> it may be to share keys for a secret-key cipher, this is an
> inherent authentication which prevents MITM attacks."
Terry Ritter is talking about authentication of the _keys_
(which is relevant if you worry about MITM attacks).
But that's very different from authentication of the _plaintext_.
If you need message authentication, you must use a MAC in addition to your
secret-key cipher; plaintext authentication often does not come for free.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Crypto/Security/Cryptanalysis Papers
Date: Sat, 29 Jan 2000 03:27:20 GMT
In article <#czxReea$GA.268@cpmsnbbsa04>,
"Joseph Ashwood" <[EMAIL PROTECTED]> wrote:
> I recently had a hard drive go bad, and I'm rebuilding what
> was on it. So I'm looking for any and all sources of
> cryptanalysis papers available. If anyone has any sources
> (I'm downloading everything from Counterpane and AES as I
> write this) please e-mail me the information (or respond on
> group, I'll find it).
http://www.dasoft.org/tom/
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Adam Durana" <[EMAIL PROTECTED]>
Subject: Block chaining
Date: Fri, 28 Jan 2000 22:44:56 -0500
I came up with a new method of block chaining, which I call "broken block
chaining" or BBC. Maybe it needs a new name? Here is how it works.
We have a cipher with a 128 bit block size. The chaining uses two sizes, a
large block size, which is 128 bits in this case, and a small block size,
let this size be 8 bits. First you take 128 bits of plaintext, encrypt it,
then you take the first 8 bits (small block size) from the left of the
ciphertext and save it, write it to a file, or whatever, this is the output.
You then move the remaining 120 bits over to the left so there are 8 bits of
free space on the right. Take 8 bits of plain text and fill in the 8 bits
of free space. Then with that 128 bits of data encrypt it again. Take the
first 8 bits from the left side of the cipher text and continue to repeat
the process until there is no more plain text.
So what do you think of this? Obviously it will take longer than current
methods of chaining, and what the "small block size" is set to will directly
affect the speed. I like this because if you use a good cipher you can
spread data accross all the data after it, and several bits before the data.
- Adam Durana
------------------------------
Date: Fri, 28 Jan 2000 23:19:31 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Crossposted-To: sci.physics
Subject: Re: Intel 810 chipset Random Number Generator
Michael Kagalenko wrote:
> Scott Nelson ([EMAIL PROTECTED]) wrote
> ]On 28 Jan 2000 (Michael Kagalenko) wrote:
> ]
> ]> More important is the disagreement about what kind of noise I am
> ]> talking about.
> ]>
> ]Why is that important?
>
> Because so far, I see the denials that the well-nown physical
> effect exists. You have a little flat-earth society here at sci.crypt.
> It's not surprising; most of the participants here never took graduate
> level course in Statistical physics.
Irrelevant.
Most of the participants are numerate. Which means they are capable of
calculating the production rate of your proposed RNG. At least three
posters have mentioned the dismal fact that the production rate, even
ignoring the lack of randomness, is extremely low.
------------------------------
From: [EMAIL PROTECTED] (John G. Otto)
Crossposted-To:
alt.privacy,alt.security.pgp,comp.security.pgp,comp.security.pgp.discuss
Subject: Re: "Trusted" CA - Oxymoron?
Date: Fri, 28 Jan 2000 20:19:56 -0800
"Douglas A. Gwyn" wrote:
> What one really needs is an irrevocable, unforgeable token of identity;
> it would constitute proof of *continuity* of identity, but of course
> not absolute identity. I.e. if the authenticator says I'm Frodo, then
> everything that has been authenticated as coming from Frodo has come
> from the same entity, but you don't necessarily know *any*thing else
> about that entity.
No, one needs to live in a world where identity is irrelevant,
where you can drive or walk down the road without being accosted
and your papers demanded, where you can trade with people equitably
and anonymously, where your "identity certificate" does not matter
but how you interact with other individuals does.
"When ID's are mandatory, its time to leave the planet." --- Robert A. Heinlein
--
John G. Otto Nisus Software, Engineering
http://www.nisus.com SuperSleuth QUED/M
http://www.mathhelp.com GIA Nisus Writer
http://www.infoclick.com Easy Alarms Mail Keeper
Opinions expressed are not those of Nisus Software.
------------------------------
From: Johnny Bravo <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.unix,comp.security
Subject: Re: How to password protect files on distribution CD
Date: Fri, 28 Jan 2000 23:22:26 +0000
On Fri, 28 Jan 2000 18:02:17 -0800, GJJ
<[EMAIL PROTECTED]> wrote:
>BTW - I have no personal or professional interests in the above
>companies and have not tried any of their products so I can't vouch for
>them...
I can; copy protection can't.
There is no possible copy protection that can't be recopied or bypassed.
If nothing else than by distributing the encrypted files with a valid
decryption key. For those silly schemes where the customer's name is used
to make an encryption key, a key generator is easy enough to reverse
engineer as the program has to take the customer name, compute the same
key to compare it against the entry. Anything the computer can do, a
cracker can duplicate, then put it into a program that does the same
calculations and generates the keys.
For larger and more complicated programs, for some it will be worth the
cost to purchase a bound manual and tech support. Some companies are
offering an outstanding product for free and making money of the support,
ala Sun Systems and the massive package Star Office.
Best Wishes,
Johnny Bravo
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: Block chaining
Date: 28 Jan 2000 21:11:18 -0800
In article <Ritk4.254$[EMAIL PROTECTED]>,
Adam Durana <[EMAIL PROTECTED]> wrote:
> I came up with a new method of block chaining, which I call "broken block
> chaining" or BBC. [...]
> So what do you think of this? Obviously it will take longer than current
> methods of chaining, and what the "small block size" is set to will directly
> affect the speed. I like this because if you use a good cipher you can
> spread data accross all the data after it, and several bits before the data.
Interesting. But do you have any applications in mind where this mode
provides a compelling advantage over the standard chaining modes?
One disadvantage is that one must have the entire ciphertext in memory
before one can start decrypting, so this is not very suitable for streaming
applications. For non-streaming applications, the performance overhead may
be problematic.
Also, the space overhead of your method is slightly larger (256 bits;
standard methods waste 128 bits). This is irrelevant for large messages,
but might be problematic if you frequently encrypt short ones.
It's not clear to me why you want to spread data across everything after
itself, but I'll note that many of the standard chaining modes also provide
this property, if you prefer it. (But one should not rely on this property
for message authentication purposes.)
As always, you'll probably want to use this with a random IV, because
otherwise stereotyped header sequences will show through in the ciphertext.
------------------------------
Date: Thu, 27 Jan 2000 22:00:11 +0000
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: *** ECC Strong and Weak combined
=====BEGIN PGP SIGNED MESSAGE=====
Greg wrote:
>
> I was doing some testing recently with my ECC code and I noticed
> that if I have a curve over a large field and a key that has the
> most significant bit set, it takes about one second to complete
> a point operation.
>
> Yet, if I keep the key value very small where, say, the 80% MSBs
> are clear, then the operation is very fast.
Yes, but don't do that. For discrete log over GF(p) you can get
away with using exponents shorter than the field size, up to a
point, but for ECC, an exponent of the same size as the field is
already as small as possible without weakening security.
> This makes me think that given a very strong public key for a
> server, a client can use a random small private key which can
> be used to quickly generate both the client's public key and
> shared secret.
This can be broken in O(2^(n/2)) work, where n is the number of
bits that can vary in the private exponent (e.g. using the
Pollard lambda algorithm).
- --
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
"Attempts to control the use of encryption technology are wrong in principle,
unworkable in practice, and damaging to the long-term economic value of the
information networks." -- UK Labour Party pre-election policy document
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOJC/xjkCAxeYt5gVAQHOMwf9H9/WSpgBK346Svdy0Rb9Fl+/30tPHPbt
VznZ4foXI2AdmEIdixRRx/0IZcTa/95rKfGVOAP/pFr03Az8edHm5lREnMdUyzrB
2r2YEBLCR7iDwpj+DU6B1IWbsPgS5M9NWN4TZJPuBkT+zq02uJh+VGl34Uebnwv7
3CMKRvrxPEiHA0PJJQVlaVWIfOErz8+NLDiTQfLQN5YcJ44S01QVqSt3TwHLdraj
gDmQ5Q1bLXBx8or3UCuzPGgxF4ATQp9TDQMvofhE3dj/LVoKFN9Dai3PZZ8astTT
35vKH4EgEwzPbCvCY+qqGj1TzjIiVZA6PJ0M4YH7UMxjoJv9uUPt7g==
=DREV
=====END PGP SIGNATURE=====
------------------------------
Date: Fri, 28 Jan 2000 01:53:12 +0000
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: ECM Factoring and RSA Speed Ups
=====BEGIN PGP SIGNED MESSAGE=====
David Hopwood wrote:
> Tom St Denis wrote:
> >
> > First off any papers floating around about ECM?
>
> Funnily enough, I was searching for exactly the same thing yesterday.
> This is what I could find on-line:
>
> P. L. Montgomery,
> A survey of modern integer factorization algorithms,
> CWI Quarterly 7 (1994), 337-366. MR 96b: 11161.
> ftp://ftp.cwi.nl/pub/pmontgom/cwisurvey.psl.Z
>
> P. L. Montgomery,
> An FFT extension of the elliptic curve method of factorization,
> Ph. D. dissertation, Mathematics, University of California at
> Los Angeles, 1992.
> ftp://ftp.cwi.nl/pub/pmontgom/ucladissertation.psl.Z
These URLs should end in ".gz". However, Winzip doesn't seem to
like them; either use gunzip, or view (as opposed to saving) the
files in Netscape, and cut-and-paste the Postscript source into
a text editor.
(I really do hate Postscript. *Please*, if you are putting papers
on-line, also put up the LaTeX or whatever original, or convert
to HTML.)
- --
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
"Attempts to control the use of encryption technology are wrong in principle,
unworkable in practice, and damaging to the long-term economic value of the
information networks." -- UK Labour Party pre-election policy document
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOJD2WjkCAxeYt5gVAQH8Hwf/UmkDkAZdG6ZAaP65cqslJvCiCCgRPVfh
kBF0vl/ChOVgGN1Ce2KJgCrfpdGVJz5DBzcAtIXxeZeO1yrt75WCxUzrGr32CB21
JH8Bv5OOBD2MiRvmRD/uUZ706WYrVuoZ5srpQR0SVOk/xC2w/ppVJzS0Na+yJQz7
YpG2YWDNq5E8S9HNiuFloslRoQlbPLP2AKb+4hJX2T3jhvQetBAQy6kVVriRfqwK
LaG3h3G7Wu0/vjP6V+rQvm88GvDBH/y/PtaEAYtkbhjyQo3NjR0FqnC8oWaGXIka
FiLwqE2SAxhZPpS0q7mZOZIx37U8MttIJkGxojtVf05y8gQbrQS9QA==
=lzX/
=====END PGP SIGNATURE=====
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: How much does it cost to share knowledge?
Date: Sat, 29 Jan 2000 05:22:10 GMT
Paul Schlyter wrote:
> That actually makes sense, because if there hadn't been any hackers,
> there would be no PC's either, because the personal computer revolution
> started among hackers.
Not really. You may be thinking of the Apple/Apple II, or even
IMSAI, but we had personal interactive computers as far back as
ENIAC. The "PC" in the Intel x86 sense originated with IBM,
hardly known as "hackers".
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Mac encryption algorithm?
Date: Sat, 29 Jan 2000 05:29:23 GMT
Paul Schlyter wrote:
> And why is this [little-endian] byte order "wrong" ?
It's pretty evident to people who've dealt extensively with both,
that little-endian is "more natural" from the point of view of
arithmetic and addressing. For example, consider how it supported
pass-by-reference integers in DEC PDP-11 FORTRAN; that was so
important that the implementation of 32-bit integers did not
match the mixed-endian storage layout of the FP-11 floating-point
unit (which included support for 32-bit integers), despite the
speed advantage had the FP-11 layout been used. With big-endian
representation, the low-level operations constantly have to take
word size into account; little-endian representation is much more
cleanly extensible.
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: How much does it cost to share knowledge?
Date: 29 Jan 2000 05:15:12 GMT
Tom St Denis <[EMAIL PROTECTED]> wrote:
> That's sad, as scientists I would think their main goal was the
> development of the human understanding of things. Math always existed
> we are just *finding* it.
That's a debatable statement. Even if it's accepted, I do not think
that the conclusion necessarily follows :
> That's why patents must be abolished. It's
> analogous to patenting a new found island because you found it first.
> That's silly.
Why did Britain "own" what is now Canada for the best part of the 17th,
18th, and 19th centuries, and depending on interpretation, part of the
20th? (do you count your independence from 1867 or from 1931?)
Because they found it first, at least with respect to the European world.
Why does someone who finds an oil field have the right to develop it?
It seems to be a generally accepted principle that someone who discovers a
natural resource has some rights over it.
it may still be silly. you will need to explain why. talk.politics.crypto
is probably a better place to do it, though (followups to this should go
there now...insh'allah).
> Common we are suppose to be evolving as a society
Says who. Towards where? With what end?
>yet we cling to some
> paper with printing on it. that's very primitive.
Under exactly which standard of primitive?
Thanks,
-David Molnar
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Classical Crypto Books
Date: Sat, 29 Jan 2000 05:33:09 GMT
Melinda Harris wrote:
> CryptoBook <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
Yes, we know they did. Why did you repeat the entire CryptoBook
posting, especially with no added commentary?
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: NEC claims New Strongest Crypto Algor
Date: Fri, 28 Jan 2000 23:13:00 -0600
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (John Sa
>
> But if there were some way to place that kind of obstruction in the
> cryptanalysts' path without such a simple way to avoid it, it would be
> useful. Creating "fake" keys that aren't used would be useless, but
> that may be another matter entirely.
>
I've brought this up before, but it is relevant: One can manufacture a
key that will work in the GVA for a given block, but it will be wrong.
Perhaps, you could do it for two, but it would be wrong.
The problem is exactly what you want, dangling the appearance of success
before the cryptanaylist, then dashing the house of cards with the next
block. In all of this, I assume reasonable security in generating a good
set of keys to begin with.
--
About injustice, the stronger I get the meaner I feel, or is it the
other way around. Do not respect sacred cows that seek to trample you while preaching
about the good they do.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Crossposted-To:
alt.privacy,alt.security.pgp,comp.security.pgp,comp.security.pgp.discuss
Subject: Re: "Trusted" CA - Oxymoron?
Date: Fri, 28 Jan 2000 23:03:44 -0600
In article <R8sk4.49056$[EMAIL PROTECTED]>, "Brian
Hetrick" <[EMAIL PROTECTED]> wrote:
> Assuring someone's identity is a hard problem, one that humanity has,
> despite thousands of years of effort, yet to solve in the "real
> world." Expecting the "digital world" to have a better solution to a
> real world problem than the real world itself is, I suspect, somewhat
> overoptimistic.
Considering that one might even want to be anonymous, yet get a reputation
with some pseudonym, it would be difficult to prove any identity in the
real world, even counter-productive to being anonymous. Yet as a trusted
voice, the anonymoous person with a certain point of view would not want
to have someone else be able to pretend to be him, and posibly ruin what
he has built up. I think there is a place for something like this.
--
About injustice, the stronger I get the meaner I feel, or is it the
other way around. Do not respect sacred cows that seek to trample you while preaching
about the good they do.
------------------------------
** 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
******************************
