Cryptography-Digest Digest #955, Volume #10 Sat, 22 Jan 00 16:13:02 EST
Contents:
Re: Beginners questions re-OTPs (Sandy Harris)
Re: from DEAL to ZEAL (David Wagner)
Re: MIRDEK: more fun with playing cards. (CLSV)
Re: Wagner et Al. (Jerry Coffin)
Re: Intel 810 chipset Random Number Generator (Scott Nelson)
Simple Equivalent keys in Serpent ([EMAIL PROTECTED])
Re: Does RSA use real prime ? (Jerry Coffin)
Re: MIRDEK: more fun with playing cards. ("r.e.s.")
Re: New Crypto Regulations (Jim)
Re: Intel 810 chipset Random Number Generator (Jerry Coffin)
Re: Does RSA use real prime ? (Tom St Denis)
Re: Transposition over ASCII-coded text (wtshaw)
Re: Combination of stream and block encryption techniques (Terry Ritter)
Re: NIST, AES at RSA conference (Terry Ritter)
Twofish question (ciphertext chaining) (Hans Petter Jansson)
Re: Transposition over ASCII-coded text ("Douglas A. Gwyn")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Sandy Harris)
Subject: Re: Beginners questions re-OTPs
Date: 22 Jan 2000 18:28:55 GMT
[EMAIL PROTECTED] (Douglas A. Gwyn) spake thus:
>Bill wrote:
>> I'll rephrase the question, If you have message(s) that were
>> encrypted with a "supposed" OTP what methodology/statistical
>> analysis would be carried out to try and break it?
>
>It's called "cryptanalysis" and cannot be boiled down to a simple
>recipe. The sci.crypt FAQ contained pointers to tutorials on C/A
>(last I looked). The classic textbooks are available from Aegean
>Park Press.
There is a one time pad FAQ. It's by someone fairly well known
(Marcus Ranum? Weiste Venema?) and is quite good. Try a web search.
www.counterpane.com has a tutorial on cryptanalysis
Kahn's "The Codebreakers" has plenty of history and examples on the
classic code-breaking techniques, none of which work against a real
OTP, but several of which might aginst bogus ones.
A bogus "one-time pad" is equivalent to a stream cipher, a method of
generating a stream of bytes to XOR with the message. Some stream ciphers
are very secure. The ones designed by anyone clueless (or dishonest)
enough to call them OTPs are likely to be dreadfully weak. Try a web
search on "stream cipher cryptanalysis", or look at Schneier and Kahn's
indexes.
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: from DEAL to ZEAL
Date: 22 Jan 2000 10:28:57 -0800
Here is a small observation on ZEAL. One property which DEAL has, but
ZEAL apparently does not, is symmetry of encryption and decryption.
Symmetry makes implementation easier, but also has a slightly less
obvious impact on security: one can readily show that the security
against chosen-plaintext and chosen-ciphertext attacks is the same for
a symmetric cipher.
For an asymmetric cipher (which ZEAL appears to be?), one must look at the
chosen-plaintext attacks and the chosen-ciphertext attacks separately:
security against chosen-plaintext attacks does not necessarily imply
security against chosen-ciphertext attacks. This is a very minor point,
but maybe it is a small reason to prefer the Feistel networks (or to
alternate between complementary round types, as in Skipjack).
------------------------------
From: CLSV <[EMAIL PROTECTED]>
Subject: Re: MIRDEK: more fun with playing cards.
Date: Sat, 22 Jan 2000 18:34:07 +0000
Paul Crowley wrote:
>
> CLSV <[EMAIL PROTECTED]> writes:
> > > When you say "one time", you mean "once per message".
> > No, I mean just once before encrypted communication starts.
> Could you be more explicit about how you then go on to encrypt more
> than one message?
> I can think of one way, which is simply to start the new message with
> the state where you left off the old message, but this requires that
> the recipient either receive all of your messages (unlikely) or at
> least know how long they all were (OK if your recipient is decrypting
> with a computer).
That would also give problems when you are
communicating with different people using the
same key. I was thinking about using special
start values of the pointers I and J as salt.
You can send them in the clear with the encrypted
message. I don't know how it affects security 'though.
> However, the requirement that you carry this state around with you is
> burdensome - with Mirdek, you can throw away your (sorted) pack of
> cards at the border, buy a new pack in a new country, and start
> encrypting again, all using only a memorised passphrase. There must
> be ways to achieve this goal with an ARC4 variant.
Well ARC4 is not sacred to me in this context. One of
its problems is that it fails to make use of powerful
operations that can be done easily by hand and inefficiently
on a computer. E.g. swapping two cards by hand is as easy
as swapping two packs of twenty cards.
> I'm enjoying this
> thread a lot and grateful to all participants!)
Indeed, I think it is a useful subject and it provides
some interesting food for thought.
Regards,
CLSV
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: Wagner et Al.
Date: Sat, 22 Jan 2000 11:47:55 -0700
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
> NTFS files are "secure" (in the sense of enforcement of permissions)
> only within the NT context. If somebody comes along and reboots the
> system with his own software, e.g. minimal Windows 9x with an NTFS
> module (yes, you can download one [RO] for free), the permissions
> are bypassed. This isn't an especially brilliant observation, but
> it needs to be kept in mind when discussing OS mechanisms for file
> security.
Quite true -- it also brings us back to topicality: if you want to
maintain security in a broader context, you have little choice but to
encrypt the data. Windows 2000, like many current OSes that purport
to be highly secure, will have native support for an encrypted file
system. I haven't studied it in detail yet, but it'll be interesting
to see whether MS screws it up as badly as they have most of their
other attempts at security...
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
From: [EMAIL PROTECTED] (Scott Nelson)
Crossposted-To: sci.physics
Subject: Re: Intel 810 chipset Random Number Generator
Reply-To: [EMAIL PROTECTED]
Date: Sat, 22 Jan 2000 18:50:40 GMT
On Fri, 21 Jan 2000 Paul Koning <[EMAIL PROTECTED]> wrote:
[snip]
>The error of a crystal oscillator comes from a number of components.
>First of all there's the manufacturing tolerance of the crystal,
>typically 0.01%. Note that in practice this means the error is
>close to -0.01% or +0.01%, a bimodal distribution. It's a bad
>mistake to think of crystal frequencies as normally distributed!
>
This is true, but very misleading. That accuracy rating is
how close it is to a particular frequency. It varies from
part to part, but a specific part doesn't. "Bad" crystals
don't vary in frequency this much, anymore than a box
of nails which is 1000+/-10 grams varies in mass.
I think the real problem with using crystals in HRNG is price.
As cheap as they are, they still aren't cheaper than
an RC circuit. Plus an RC has "better" noise
characteristics, since an RC is noisier.
Scott Nelson <[EMAIL PROTECTED]>
------------------------------
From: [EMAIL PROTECTED]
Subject: Simple Equivalent keys in Serpent
Date: Sat, 22 Jan 2000 18:48:36 GMT
Hello All,
First off, I don't think this is a weakness in Serpent. It is an
oddity however.
>From looking at the key schedule for Serpent, I believe each 128 and
192 bit key has an equivalent 256 bit key.
Quoting from 'Serpent: A Propsal for the Advanced Encryption Standard'
...
short keys with less than 256 bits are mapped to full-length keys of
256 bits by appending one '1' bit to the MSB end, followed by as many
'0' bits as required to make up 256 bits.
...
Since the key schedule itself does -not- take into account the length
of the input key and there is no restriction on the selection of 256
bits keys, it appears that each 128 and 192 bit key has a 256 bit
equivalent.
By contrast, RC6 and Rijndael both incorporate the length of the input
key into the key schedule. In either RC6 or Rijndael, a short key will
not map to the same rounds keys as a full length key.
A theoritical exploit of the Serpent schedule:
1. Capture plain/cipher text for a 256 bit key encrpytion
2. Capture plain/cipher text for a 128 bit key encryption
3. Notice that the cipher text is the same for both
4. Brute force the 128 bit and break the 256 bit key.
Not very practical but intesting.
--Matthew
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: Does RSA use real prime ?
Date: Sat, 22 Jan 2000 12:15:42 -0700
In article <86cp51$dar$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] says...
> RSA related cryptosystem often refers to the lenghth of key. For example, a 1024 bit
>PGP keypairs...
> Since 1024 bit is not a small number, I am curious how programs like PGP can find a
>big prime so rapidly.
> I hear someone that these program does not use real prime. Instead, they use
>numbers which are very possbile real primes on a
> statistical base. Is this true ?
There are both deterministic methods and probabilistic methods. Most
people use the latter because they're a lot quicker, and can be made
arbitrarily accurate -- to the point that a false positive is FAR more
likely to be due to your computer malfunctioning than to the test
having come up with the wrong answer.
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
From: "r.e.s." <[EMAIL PROTECTED]>
Subject: Re: MIRDEK: more fun with playing cards.
Date: Sat, 22 Jan 2000 11:19:34 -0800
"Paul Crowley" <[EMAIL PROTECTED]> wrote ...
: "r.e.s." <[EMAIL PROTECTED]> writes:
: > Concerning the alleged bias in ARC4, imo it's so small as to be
: > negligible in the context of hand ciphers.
:
: I'm not sure why you use the word "alleged" here. Also we don't yet
: know how large it would be for the variant you propose.
I say "alleged" to mean that bias is being asserted, not that
the assertion is without some evidence. You're right, of course
that "ARC4-52" requires further evaluation (as does MIRDEK and
Solitaire).
A side issue:
If you required "just under 56 trillion samples of RC4 output" to
confirm a bias in ARC4, does that suggest that an adversary would
need a similar volume of ciphertext in order to capitalize on that
bias?
It seems likely to me that there are always values of eps > 0
such that the mere *existence* of bias < eps is without practical
significance for the cipher. So we want to know not only, e.g.,
a confidence interval for the bias with a reasonable level of
confidence, but also we need to determine whether the results are
of practical significance.
--
r.e.s. "Mistr Typo"
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Jim)
Subject: Re: New Crypto Regulations
Date: Sat, 22 Jan 2000 19:20:08 GMT
Reply-To: [EMAIL PROTECTED]
On Fri, 21 Jan 2000 13:21:30 -0700, "John E. Kuslich" <[EMAIL PROTECTED]> wrote:
>
>
>Bill Unruh wrote:
>>
>> In <[EMAIL PROTECTED]> "John E. Kuslich" <[EMAIL PROTECTED]> writes:
>>
>> >These crypto regulations seem to have their basis in an emergency
>> >executive order and based on treaty arrangements made by State
>> >Department officials who may have exceeded their authority in binding
>> >the US government to a set of international "arrangements" with regard
>> >to the control of the sale of munitions.
>>
>> It was primarily the US who pushed for those arrangements.
>
>Yes, precisely. Why????????????????????????
>
>What earthly good do they do? (The geanie being out of the bottle etc.)
>
>The government of Iran, for example, obviously can get any crypto they
>want.
And why shouldn't they?
--
Jim,
nordland at lineone.net
amadeus at netcomuk.co.uk
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Crossposted-To: sci.physics
Subject: Re: Intel 810 chipset Random Number Generator
Date: Sat, 22 Jan 2000 12:24:27 -0700
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
says...
[ ... ]
> I think the real problem with using crystals in HRNG is price.
> As cheap as they are, they still aren't cheaper than
> an RC circuit. Plus an RC has "better" noise
> characteristics, since an RC is noisier.
It comes down to this: the point of putting a crystal in an oscillator
is to eliminate as much randomness as possible. If you're designing
something specifically to generate randomness, that's obviously not a
good thing to do. An oscillator without a crystal will produce much
more random output, and be a lot cheaper and simpler to build as well.
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Does RSA use real prime ?
Date: Sat, 22 Jan 2000 19:42:30 GMT
In article <86cp51$dar$[EMAIL PROTECTED]>,
"Hank" <[EMAIL PROTECTED]> wrote:
> RSA related cryptosystem often refers to the lenghth of key. For
example, a 1024 bit PGP keypairs...
> Since 1024 bit is not a small number, I am curious how programs like
PGP can find a big prime so rapidly.
> I hear someone that these program does not use real prime. Instead,
they use numbers which are very possbile real primes on a
> statistical base. Is this true ?
>
Yes it's true. Factoring a large N bit number will take too long for
most cases. So they use probable primality testers. I wouldn't
dismiss them so casually. For the most part the chances your two
primes in RSA [say as made by PGP] are not prime is less then 1 in
2^51. Even if they are composite the chances that you decrypt/encrypt
messages sucessfully more then once is way smaller.
See the decryption exponent 'e' is found by taking d^-1 mod (p-1)(q-
1). If either q or p are not prime then 'e' will not be the inverse
exponent mod pq.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Transposition over ASCII-coded text
Date: Sat, 22 Jan 2000 14:32:12 -0600
In article <86an34$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
(Guy Macon) wrote:
>
> I am an engineer who manufactures CDs and DVDs. It is part of the
> official Red Book CD Spec to take a single chunk of data that has
> an error correcting code and splash it all over the CD so that
> a bit of dirt will kill 1 bit out of 1000 error corrected blocks
> rather than 1000 bits out of 1 error corrected block.
>
> You can drill a 1/8 inch hole in a CD and it will play without
> error. At 1.6 uM track spacing and 0.83 minimum pit length,
> that's a lot of bits you just destroyed!
>
This is exactly the kinds of tests that kill lots of deficient crypto
schemes. People forget that comunications fragility is a fact that
sometimes bites you. The answer is redundancy, which is the same thing on
a different level...backups will eventually save most of what you have
lost.
Holographic images survive flaws as well, where breaking a glass plate may
mean that each of the pieces will work, just with a diminished and ragged
aperature due to the break.
--
To prevent the comprimise of with the most common configuration
of computers is something like preventing a sculptor from being too original. If a
computer design is corruptable, it will be.
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Combination of stream and block encryption techniques
Date: Sat, 22 Jan 2000 20:47:01 GMT
On Sat, 22 Jan 2000 09:24:27 +0100, in
<[EMAIL PROTECTED]>, in sci.crypt Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:
>Terry Ritter schrieb:
>>
>[...]
>But we should be very careful to believe in thing that people simply
>tell us (claim) without giving us concrete details.
The whole point of this was your claim that stream ciphers and block
ciphers are essentially the same or at least have no sensible
distinction, and here it is again:
>>>On Thu, 20 Jan 2000 14:39:49 +0100, in <[EMAIL PROTECTED]>,
>>>in sci.crypt Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>>>>[...]
>>>>The point worthy to be repeated is that one need not keep a strict
>>>>distinction between stream and block ciphers, i.e. there is no sharp
>>>>boundary between these...
In my response, I described just such distinctions, and the beneficial
implications to cipher design accruing from such classification.
In my last message, I gave details about how such a "filtering" stream
cipher *would* fit into the stream cipher classification, but *not* if
that classification was based, as you suggested, on the presence of a
keying sequence. True, my example was a weak cipher, but if you think
a cipher is only a cipher if it is strong, you might as well forget
about Simple Substitution entirely. And if you are not ready to
ignore Simple Substitution in cipher analysis, not seeing my weak
example as a valid counterexample seems rather inconsistent.
If you want a more valid cipher in this category, surely we can talk
about a cipher in which plaintext shifts into a fairly long shift
register. The state value in the shift register is partitioned,
selected, and combined in multiple ways. Then, when the next
plaintext character shifts in, ciphertext shifts out, and the internal
operations occur again. This will be reversible if the internal
combining is reversible. I suppose we might call this "plaintext
feedforward (PFF)" or something, but that really does not capture the
flavor of the operation. There is no internal or external keystream
to recognize, so if we use "keystream" as the differentiating
property, this must be a *block* cipher, even though the structure can
cipher bit-by-bit or char-by-char.
Accordingly I suggest that a "keystream" distinction is not useful to
differentiate "stream" from "block." Further, it is not yet
particularly useful to differentiate "keystream" from "filtering"
stream ciphers, since we know so little about the consequences of the
latter.
>[...]
>I suspect that you misunderstood me a bit. The topic is not to
>seek diversity, to find more classification categories in the
>first place, but to 'unify' them, in particular to take away the big
>boundary between stream encryption and block encrytion techniques.
"The topic," as you put it, is the claim that there is no sensible
distinction between stream and block ciphers, and that claim is false.
>On the other hand, if people invent a new technique (here digital
>filtering), then there must be something basically different
>from the existing one (key stream) and there must be some concrete
>benefits/advantages that motivated the new design. Aren't these
>the 'consequences' in the present context?
The point of a distinction between ciphers is to differentiate some
part of their operation with respect to cryptography. Not having a
body of work in this area would seem to make implied consequences
difficult to pin down.
>Perhaps I may take this opportunity to give what is in my view
>a (rather trivial/primitive) combination of stream and block
>encryption techniques. One uses a PRNG to generate keys for a
>block encryption algorithm. (Cf. my previous proposal to defeat
>differential analysis through using variable keys for DES.)
This is straightforward and has been mentioned by many people many
times. Since block ciphers are just large Simple Substitutions, I see
it as the pseudorandom selection of alphabets in a polyalphabetic
stream. It is a stream meta-cipher composed of block cipher
transformations, and -- with an appropriately strong sequence -- is
certainly stronger than CBC.
Here we can say "certainly stronger than CBC" because additional work
is required to resolve the sequence generator, no matter how little
that work may be. I see this logic as an advantage which accrues to
systems with multiple layers of different ciphering puzzles. Further,
hopefully, the information required to penetrate one layer may
"commit" the attacker (in an information sense) to an approach which
simply does not admit the solution of the other layers.
I suppose the reason sequence-streamed DES is rarely done in practice
is the same reason that multi-ciphering is rarely done: People don't
think it is worth the extra trouble.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: NIST, AES at RSA conference
Date: Sat, 22 Jan 2000 20:47:09 GMT
On Sat, 22 Jan 2000 12:40:20 GMT, in <[EMAIL PROTECTED]>,
in sci.crypt [EMAIL PROTECTED] (John Savard) wrote:
>[...]
>Although there is no way to prove that there is not some devastating
>attack on any or all of the AES candidates that just hasn't been
>discovered yet, it's unlikely that money could buy cryptanalysis of
>them that would be significantly better than what they've recieved
>already.
"Unlikely?" Really? And just what would you say that "unlikely"
probability is? How did you reach that value? Since when did pulling
conclusions out of the air become responsible scientific debate?
By using the term "unlikely" you present the appearance of knowledge
which you do not in fact possess. Furthermore, your "conclusion"
contradicts my experience and that of society:
A dedicated group of good -- but not necessarily world-class -- minds
*can* make world-class progress, especially if well-organized,
well-funded, and well-motivated. Note that this modern, corporate
approach to research is largely unavailable without a reasonable
expectation of profit. Moreover, the progress thus attained is more
dependable than the "flash of genius" those here seem to depend upon,
given the minimal time individual crypto gods may be willing or able
to allocate to the project.
It is all very fine to get a few weeks of free work from crypto gods,
but real progress is often made bit-by-bit and day-by-day with the
unrelenting long-term effort of a well-funded task force made up of
many minds. We should not be asking for more crypto-gods; we should
instead be funding crypto R&D and -- like magic! -- new crypto-gods
will appear.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: [EMAIL PROTECTED] (Hans Petter Jansson)
Subject: Twofish question (ciphertext chaining)
Date: 22 Jan 2000 20:59:32 GMT
Reply-To: [EMAIL PROTECTED]
* Context:
I'm using the Twofish symmetric cipher in CFB mode to encrypt data streams
with 8-bit atoms. I'm not using CBC, as data size expansion (and/or further
protocol) is undesirable in this case.
* Problem:
CFB is slow, as every byte transmitted/received yields one encryption of the
IV (vectors).
* Tentative solution:
Cycle through the IV and XOR as many bytes as possible before permuting the
IV.
With an IV of 16 bytes, start by XORing the first byte of the IV with the
first byte of input, then the second byte of the IV with the second byte of
input, et cetera.
Whenever the last byte of the IV has been used, permute it and start XORing
with its first byte (next cycle).
* Questions:
Is this cryptographically sound, or is there a good chance that it's weak?
How should the permutation step be done - e.g. by replacing the last IV with
the last 16 bytes after XOR, and encrypt that, or by shifting in a certain
amount of bytes, and encrypt that?
There are several possibilities, which one makes the most sense?
--
Hans Petter K. Jansson Simplemente Soluciones
[EMAIL PROTECTED] http://simplemente.net/
Nicol�s San Juan #239 Tel: +52 5 639 1261
Col. Del Valle CP. 03100, M�xico D.F, MEXICO Fax: +52 5 639 4860
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Transposition over ASCII-coded text
Date: Sat, 22 Jan 2000 21:02:46 GMT
Mok-Kong Shen wrote:
> If that interleaving is very systematic, would you consider it
> as a (non-trivial) scrambling suitable for encryption purposes?
Error correction and encryption have quite different goals.
------------------------------
** 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
******************************
