Cryptography-Digest Digest #953, Volume #10 Sat, 22 Jan 00 05:13:01 EST
Contents:
Re: Transposition over ASCII-coded text ("Douglas A. Gwyn")
Re: New Crypto Regulations ("Douglas A. Gwyn")
Re: Wagner et Al. ("Douglas A. Gwyn")
Re: MIRDEK: more fun with playing cards. ("Joseph Ashwood")
Re: MIRDEK: more fun with playing cards. ("Joseph Ashwood")
Re: What's with transposition? ("Douglas A. Gwyn")
Re: NIST, AES at RSA conference (Mok-Kong Shen)
Re: NIST, AES at RSA conference (Mok-Kong Shen)
Re: Transposition over ASCII-coded text (Mok-Kong Shen)
Re: Combination of stream and block encryption techniques (Mok-Kong Shen)
Re: Combination of stream and block encryption techniques (Mok-Kong Shen)
Re: Transposition over ASCII-coded text (Mok-Kong Shen)
Re: Intel 810 chipset Random Number Generator (Guy Macon)
Re: Predicting Graphs. ("Joseph Ashwood")
Re: MIRDEK: more fun with playing cards. ("r.e.s.")
----------------------------------------------------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Transposition over ASCII-coded text
Date: Sat, 22 Jan 2000 07:05:26 GMT
Mok-Kong Shen wrote:
> I am a bit surprised to know this. The books on error-correcting
> codes don't seem to mention that the data has first to be 'scrambled'
> in some way and then the specific error-correcting code is applied.
Sure they do; it's called "interleaving" and is an important
aspect of many schemes for defeating bursty noise.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: New Crypto Regulations
Date: Sat, 22 Jan 2000 07:03:32 GMT
"John E. Kuslich" wrote:
> Bill Unruh wrote:
> > It was primarily the US who pushed for those arrangements.
> Yes, precisely. Why????????????????????????
It wasn't the "US", it was the tiny portion of it embedded in
the Executive Branch. In fact they did that right after Congress
had nixed their plans for domestic key escrow (the so-called
"Clipper chip" initiative). One thing about Clinton/Gore and
the so-called "liberals" in general: you can't afford to relax
after defeating one of their schemes, because they're so sure
they know what is best for everyone that they just try again
from another angle, but a bit sneakier each time. I'm sure
part of the "why" is in order to support an argument that
"we need key escrow to cooperate with our foreign partners".
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Wagner et Al.
Date: Sat, 22 Jan 2000 07:14:47 GMT
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.
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: MIRDEK: more fun with playing cards.
Date: Fri, 21 Jan 2000 22:57:54 -0800
"CLSV" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...
> I don't think I understand what you mean?
> Personally I would communicate a random
> permutation of 52 cards as a key and skip
> the setup.
The problem with that is that the needed resources to communicate with
multiple people grows very quickly, at exactly one 52/54 card/numeric order
per person, however if you have a static beginning permutation of 52 or 54
cards/numbers, and simply generate a new permutation based on the key, you
have the need to store the permutation once and a relatively small key from
there on. Also if one deck is compromised, there is the distinct possibility
of not having the complete key compromised, very much like the ATM systems.
If you're communicating with only one entity, or you have a single powerful
entity in the middle (clients/server model), then it is concievable to go
keyless.
Joe
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: MIRDEK: more fun with playing cards.
Date: Fri, 21 Jan 2000 23:19:43 -0800
> Could you give specific examples of these two claims.
No problem.
First:
Take ARC4 and give it the passphrase of
255, 254, 253, 252, . . . .2, 1, 0
Every value in the array becomes identical, this is a very bad idea,
especially since we only have one of each card. This is one of 256 in the
worst cases, but there are a large number of others.
Second:
I can choose a password such that an arbitrary card is outside of the valid
bounds, this could be partially be remedied by the use of modular division,
but that introduces quite string biases for lower order values, amplifying
the effect of the first. This problem can be reduced by using absurdly large
values as the input to the modular division, but that's simply not workable
in this situation. As a specific example:
When using addition card with value 1, plus key of highest value = value
outside bounds
Using XOR we must use a 0-63 range: card value = 15, key = 48 -> value = 63
Joe
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: What's with transposition?
Date: Sat, 22 Jan 2000 07:30:06 GMT
"Douglas A. Gwyn" wrote:
> (Correlation reduces to counting matching bits.)
I don't know why I said that. The bit *patterns* being
formed must be measured against the source model (e.g.
add log-likelihood ratios).
..01.. P=.1 (for a model where change is less likely than
..11.. P=.4 repeating the previous bit)
..10.. P=.1
..01.. P=.1
..01.. P=.1
..00.. P=.4
..10.. P=.1
Assuming a "window" of 7 bits. The relative likelihod
for each possible window position is all that is needed;
net P=.0000016 for this alignment is compared to the next:
..01.. .1
..10.. .1
..11.. .4
..01.. .1
..00.. .4
..00.. .4
..11.. .4
net P=.0000256 which makes this alignment 16 times more
likely than the first one. Repeat for every position..
Note that with *this* particular source model, it
reduces to counting matching bits, but that's not true
in the general case.
Also note that matching such a short sample isn't very
reliable, so in practice one would have to juggle several
of the better column alignments to find the best overall.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: NIST, AES at RSA conference
Date: Sat, 22 Jan 2000 09:24:16 +0100
Nicol So schrieb:
>
> Serge Vaudenay wrote:
> >
> > The AES process is the only standardization process where
> > cryptanalysts work for free.
>
> I don't see anything wrong with that. I'm not aware of any standards
> activities in which participants are paid for their participation. Most
> often, the individuals attending standards meeting are paid by their
> employers, who *are* the real participants. The participating
> organizations absorb the travel expenses of their own employees and
> sometimes sponsor the meetings. If you are a self-employed consultant,
> then you don't get paid, period. Of course, the participants believe
> that the standards will somehow benefit themselves, but standards often
> benefit many more parties than just the participants, and they don't
> seem to mind.
Oh, in that case the participants are the 'representatives' of
the companies and they have their salaries. If you consider the
companies as 'legal persons' (they are), then they are not only
doing standardization work 'for free', they are even paying money
for doing that work!! I happened to be previously involved in some
standardization work. I can say that there are sufficient indications
(no 'proof') that, while standardization is advantageous to the
participating companies, they also sometimes wish to see the
standardization process to proceed in a way that is particularly
beneficial to them (individually).
> Think about it, people do unpaid charity work every day, and most of
> these good-hearted individuals don't get any special recognition.
> Those who don't feel like participating simply don't. You can think of
> participating in the AES process as public service. If you don't feel
> like participating, just let other volunteers do it.
A very interesting view point. I like to propose that those who do
such 'charity' work in the case of AES be given oneday gold medals
for contributions to the well-being of humanity.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: NIST, AES at RSA conference
Date: Sat, 22 Jan 2000 09:24:22 +0100
Hammer wrote:
>
> Would there not be - even if only for career/ego satisfaction - at
> least some cross-checking within the teams? In some fields, I think
> this would be done in hopes of eliminating one of the other candidates
> by finding a weakness, therein furthering the chances of said teams'
> submission winning? (theoretical question)
In scientific matters like the present one, the competition does
result in one team carefully looking into the work of the others.
In other fields, this may not be true. For instance, in building
industry, there could be (illegal) behind-the-scene arrangements
among the companies that bid for a certain project (such that
one company wins the bid at a higher price than actually need
to be).
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Transposition over ASCII-coded text
Date: Sat, 22 Jan 2000 09:24:09 +0100
Guy Macon wrote:
>
> >I am a bit surprised to know this. The books on error-correcting
> >codes don't seem to mention that the data has first to be 'scrambled'
> >in some way and then the specific error-correcting code is applied.
> >Or do you mean that using an error-correcting code IS by itself doing
> >'scrambling'? (The redundancy needed for correction is contained in
> >the error-correcting code.) Could you please name a book and the
> >page number where one can find that this (i.e. first 'scrambling'
> >and then applying a code that has redundancy) is indeed the case?
>
> 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!
>
> [ http://www.sel.sony.com/SEL/consumer/dvd/about_feat.html ]
Could you explain shortly in mathematical terms what is that
'splashing'? Are you distributing (rearranging) the bit sequences
in some very systematic way? (Otherwise, how could error correction
be carried out, in case of need?) If that is the case, then this
process is hardly a 'scrambling' in the sense of encryption, IMHO.)
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Combination of stream and block encryption techniques
Date: Sat, 22 Jan 2000 09:24:27 +0100
Terry Ritter schrieb:
>
> >> No, sorry. There supposedly is a class of stream cipher which appears
> >> to function somewhat like a digital filter (input plaintext, output
> >> ciphertext), and thus does not need or use a key stream, nor do they
> >> generate a keystream internally. Unfortunately, I have not seen a
> >> real example, and cannot imagine how any such approach could hope to
> >> be secure. Others who have seen actual designs have been convinced,
> >> however.
> >
> >Your information is rather vague for me. Could you please give
> >literature references so that one could find more concrete stuffs
> >about that? I suppose one has to look into that 'black box' to see
> >what it really is.
>
> If I had a literature reference I would be citing it.
But we should be very careful to believe in thing that people simply
tell us (claim) without giving us concrete details.
> >> We could of course subdivide stream ciphers into keystream and
> >> filtering approaches. But in my view the reason for making categories
> >> is to provide insight into consequences of design, and I don't know
> >> the consequences here. So at this point the distinction seems rather
> >> meaningless.
> >
> >I don't yet fully understand your sentences. You said on the one
> >hand that making a distinction 'provides insight into consequences
> >of design ' and on the other hand that you don't know the
> >'consequences'. Was that simply a paraphrase of 'making a distinction
> >is nonsense' or did you mean something quite different? (Sorry for my
> >poor English comprehension capability.)
>
> My purpose in making distinctions between ciphers is to support
> comparison and contrast for the purpose of understanding operation.
> Seeing a block cipher as a form of Simple Substitution, and, thus,
> having all the potential weaknesses of Simple Substitution, is a case
> in point.
>
> We can propose any number of new categories, up to and including a
> different one for each and every cipher, as is often done, but that is
> also analytically unrewarding. The ideal situation is to find a
> Boolean distinction which inherently leads to different consequences
> on each side. Then we can relate the ciphers on each side as
> variations on a theme, with similar essential weaknesses and, perhaps,
> strengths.
>
> Since I have no knowledge of the "other" stream cipher category --
> other than it exists -- I have no consequences for it, and so find the
> use of that category currently unrewarding.
>
> One sort of design like this might be to feed plaintext into a LFSR
> with arbitrary feedback taps and an initial state. A plaintext bit
> goes in, a ciphertext bit comes out. We might see this as more of a
> "scrambler" than a cipher, but it is certainly a form of stream
> "ciphering" without a keystream. Now we wonder if it could be made
> secure.
>
> It seems to me that a purely linear system should be directly solvable
> with known plaintext. Thus I would suppose that in a real system a
> good deal of it would be nonlinear, with an appropriate math basis to
> somehow support deciphering.
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.
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?
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.)
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Combination of stream and block encryption techniques
Date: Sat, 22 Jan 2000 09:24:32 +0100
Douglas A. Gwyn wrote:
>
> Mok-Kong Shen wrote:
> > Could we perhaps say that the fundamental component of a stream
> > cipher is its key stream,
>
> No! That's just the most mindless implementation.
> Real-world stream ciphers tend not to be of that form.
Please kindly expain a bit. If key stream is not the fundamental
component of a stream cipher, what is the fundamental component?
Could we have a stream cipher without a key stream? (Terry Ritter
did mention one, but very unfortunately he couldn't give any
literature reference, excepting that he has sometime before heard
someone saying something about that.)
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Transposition over ASCII-coded text
Date: Sat, 22 Jan 2000 09:31:06 +0100
Douglas A. Gwyn wrote:
>
> Mok-Kong Shen wrote:
> > I am a bit surprised to know this. The books on error-correcting
> > codes don't seem to mention that the data has first to be 'scrambled'
> > in some way and then the specific error-correcting code is applied.
>
> Sure they do; it's called "interleaving" and is an important
> aspect of many schemes for defeating bursty noise.
If that interleaving is very systematic, would you consider it
as a (non-trivial) scrambling suitable for encryption purposes?
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Intel 810 chipset Random Number Generator
Date: 22 Jan 2000 03:41:27 EST
In article <86au71$m0n$[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Michael
Kagalenko) wrote:
>
>Guy Macon ([EMAIL PROTECTED]) wrote
>]
>]I can see the logic behind trying, but not if you are looking for
>]a good RNG. But what if you are looking for a cheap RNG?
>]a cheap crystal (or, better yet, ceramic) oscillator costs very
>]little, and hooks up to a serial or parallel port easily, and is
>]pretty much immune to 60 Hz electrical noise. I agree with
>]everything said about the lack of randomness, though. You really
>]are just measuring fine differences in the time between reads
>]of your serial/parallel port. Such a circuit, if Von Neuman
>]compensated and exlusive or'ed with the output of the best PRNG
>]you can program, would seem to be, on a practical level, much
>]superior to the PRNG alone.
>
> No. You are wrong. So long as you can reliably count the number of cycles
> of quartz crystal, you can use this to recover thermally random numbers.
> Temperature dependence may be indeed a proble, but it can be accounted
> for either by thermostabilising or by simply measuring it and feeding
> it into computational process.
I made at least six claims in the paragraph above, and I cannot
tell from your response exactly what I wrote that prompted the
"You are wrong" comment. Could you elaborate as to exactly what
you are disagreeing with? I stand by what I wrote above.
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Predicting Graphs.
Date: Sat, 22 Jan 2000 00:58:18 -0800
The answer is that in some cases yes, and in others no. And if you tell us
what you're thinking of doing then we can actually give you a better answer.
Joe
------------------------------
From: "r.e.s." <[EMAIL PROTECTED]>
Subject: Re: MIRDEK: more fun with playing cards.
Date: Sat, 22 Jan 2000 02:06:43 -0800
"Joseph Ashwood" <[EMAIL PROTECTED]> wrote ...
: > Could you give specific examples of these two claims.
: No problem.
:
: First:
:
: Take ARC4 and give it the passphrase of
: 255, 254, 253, 252, . . . .2, 1, 0
:
: Every value in the array becomes identical, this is a very bad idea,
: especially since we only have one of each card. This is one of 256
: in the worst cases, but there are a large number of others.
Every value in *what* array becomes identical?
ARC4's state-vector array is always some permutation
of 256 *distinct* values 0,1,2,...,255.
"ARC4-52", to mirror ARC4, would use an alphabet of 52
symbols (instead of 256) for both the state-vector and
for key-data. Maybe you were thinking that a 256-symbol
character set would still be used in ARC4-52?
(The state-vector will have length 52, and will always be
a permutation of the 52-symbol alphabet.)
If you're concerned about the alphabet being 52 symbols
instead of 26, this is no problem, because we could simply
have keys that use, say, both upper & lower case letters
to get 52 ordinary letters a-z,A-Z with values 0-25,26-51
respectively.
: Second:
:
: I can choose a password such that an arbitrary card is outside of the
valid
: bounds, this could be partially be remedied by the use of modular
division,
: but that introduces quite string biases for lower order values, amplifying
: the effect of the first. This problem can be reduced by using absurdly
large
: values as the input to the modular division, but that's simply not
workable
: in this situation. As a specific example:
: When using addition card with value 1, plus key of highest value = value
: outside bounds
: Using XOR we must use a 0-63 range: card value = 15, key = 48 -> value =
63
It looks to me like there is a misunderstanding about
the size of the character set, perhaps.
--
r.e.s. "Mistr Typo"
[EMAIL PROTECTED]
------------------------------
** 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
******************************
