Cryptography-Digest Digest #581, Volume #13 Sun, 28 Jan 01 14:13:00 EST
Contents:
Re: Windows encryption: API and file system (Daniel James)
Re: Dynamic Transposition Revisited (long) (Benjamin Goldberg)
Re: Cryptographic Windows APIs or OCX? ("Augusto Jun Devegili")
Re: Why Microsoft's Product Activation Stinks (phil hunt)
Re: Why Microsoft's Product Activation Stinks (phil hunt)
Re: How many bits of security can a password give? (Rex Stewart)
Re: Dynamic Transposition Revisited (long) (Mok-Kong Shen)
Re: Dynamic Transposition Revisited (long) (John Savard)
----------------------------------------------------------------------------
From: Daniel James <[EMAIL PROTECTED]>
Subject: Re: Windows encryption: API and file system
Date: Sun, 28 Jan 2001 12:13:09 GMT
Reply-To: [EMAIL PROTECTED]
In article <[EMAIL PROTECTED]>, Wtshaw
wrote:
> Writing temporary files or to swapable memory is *anti*security
> oriented, especially since neither is necessary for encryption.
Writing a temporary file is done out of a desire to be able to
recover the data if the encryption process is interrupted by some
fatal error. Usually it is the /encrypted/ version of the file that
is written as a temporary, and only when the encrypted file has been
completely written to disk is the unencrypted file destroyed. I don't
know exactly how NT carries out this process, if the 'destruction' of
the plaintext file is not implemented so as to overwrite it first
then that is an unforgivable weakness.
Any RAM used for temporary in-memory copies should be overwritten
before being released (I think NT does this correctly?) and should
not be swapped out.
> These wrong headed approaches were developed for early low-RAM
> computers, and infect those who know no better or fear that we
> will learn easy solutions to bad security..
Even on today's big NT machines you can't rely on being able to store
the whole of a disk file in physical memory at one time while you
encrypt it.
Cheers,
Daniel.
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: Dynamic Transposition Revisited (long)
Date: Sun, 28 Jan 2001 13:10:28 GMT
John Savard wrote:
[snip]
> >Have you already decided on the conclusions, such that any argument
> >which does not reach them must be "in no way a valid argument"?
>
> I had no problem accepting that DES cannot produce all (2^64)!
> possible codebooks. As soon as you first said that, I agreed, as it is
> something obviously true.
>
> The point I was trying to make was that transposing bits doesn't
> produce all possible codebooks of balanced blocks, and it looked to
> me, until the post I replied to, that that wasn't clear.
We don't need to produce all possible *codebooks*, just all possible
*codes*. You seem to want:
ForEach k ( k is a key )
DT_k produces one of (N!/(N/2!)(N/2!))! substitutions.
This is indeed something which DT does NOT do. However, it's not
needed. We just need for any input code to be able to produce any of
the possible output codes, given an appropriate key. Since this english
sentence is slightly ambiguous, I'll say it mathematically:
ForAll pt, ct ( pt, ct are bit balanced blocks )
ThereExists k ( k is a PRNG state )
DT_k(pt) = ct
This is like saying [for OTP]
ForAll pt, ct ( pt, ct are equal length bitstrings )
ThereExists k ( z is bitstring with length equal to pt )
XOR(pt,k) = ct
> That all possible codebooks, and not all possible transpositions, is
> the proper equivalent to all possible codebooks in DES is the point I
> have been - repetitiously - dealing with. So I don't think I've
> retreated in any way from what I have been saying.
I think I might be able to say
ForAll pt, ct ( pt, ct are length 64 bistrings )
ThereExists k ( k is a PRNG state )
yourDES_k(pt) = ct
However, it is just as impossible, if not impossibler, to randomly
select from all (2^64)! substitutions as it is to randomly select from
all (N!/(N/2!)(N/2)!)! [bit balanced] substitutions (dynamic keying or
not).
[snip]
> >>Neither a block cipher nor transposition provides all possible
> >>substitutions of input blocks to output blocks.
>
> >A transposition does not provide all substitutions? What is wrong
> >with this picture?
>
> >Since a substitution cipher *does* substitutions, it is not entirely
> >unreasonable to expect it to do all of them.
>
> >Since a transposition cipher does *not* do substitutions, it is quite
> >*un*reasonable to expect that.
>
> >With such an argument, you are being unreasonable, as well as
> >irrelevant.
>
> From the Opponent's point of view, if Cipher 1 takes general blocks IN
> and puts general blocks OUT, and Cipher 2 takes balanced blocks IN and
> puts general blocks OUT, the fact that neither cipher 1 nor cipher 2
> produces all possible input block/output block codebooks is what
> counts.
Whoops, where do you get off converting balanced blocks to general
blocks?
> That Cipher 1 fails to do so because it is four rounds of DES, and
> Cipher 2 fails to do so because it is a transposition ... well, while
> the detailed structure of the cipher one is attacking is very
> important to the cryptanalyst, being a transposition is not some kind
> of "excuse".
I have no clue what you just said here. Would you mind rephrasing that?
> >Since Dynamic Transposition provides all of its strength in the
> >original design, it does not need to be multiple ciphered with
> >itself. And, indeed, multiple ciphering with itself alone will not
> >provide additional strength. (I just note that we could design a
> >Dynamic Transposition cipher with a real keyspace of tens of
> >thousands of bits, were that to be desirable.)
>
> >How is being too strong suddenly a weakness, and how is this any sort
> >of reasonable argument at all?
>
> Not being able to _gain_ strength is a weakness.
Does that mean that OTP has a weakness? You can't double encipher with
OTP and gain strength.
IIUC, what Ritter mean by "multiple ciphering with itself alone will not
provide additional strength," was that if encipher the message with DT,
and without using a new key/altering the state, encipher again, the
cipher will not be stronger. This is analogous to the following:
Here's cipher 1, it uses a keystream generator:
pt, ct = plaintext, ciphertext
ks = The first |pt| words of keystream
ct = pt XOR ks
Here's cipher 2, it also uses a keystream generator:
pt, ct = plaintext, ciphertext
ks1 = The first |pt| words of keystream
ks2 = The next |pt| words of keystream
ct = pt XOR ks1 XOR ks2
Is cipher 2 stronger than cipher 1? Ritter is saying, that with DT as
the combiner, cipher 2 is not stronger than cipher 1... no matter how
many times one adds part of the keystream, the amount of work needed to
attack is equal to the amount of work needed to brute force the key.
Of course, this doesn't mean you can't make it stronger... it just means
that the only way to make it stronger is to lengthen the key.
[snip]
> >What I think is that you have this idea for a cipher of your own --
> >not Dynamic Transposition at all, but using transposition -- which
> >you would really prefer to discuss but just have not done so. The
> >result is that it gets tangled into the discussion of Dynamic
> >Transposition in ways that are difficult to separate. Don't do that.
> >If you want to discuss your design, put it out in a forthright
> >manner.
>
> Well, I pointed you at my 'Large-Key Brainstorm'. I'm saying that two
> transpositions are _roughly_ comparable to four rounds of DES, except
> that Dynamic Transposition can be scaled up to much larger block
> sizes.
>
> So I am comparing DT to 'another cipher', basically in respect of my
> original argument that the (admittedly, trifling) bandwidth cost of DT
> is _unnecessary_ since DT can be equalled in the substitution world.
Suppose we are working with 64 bit blocks, and we have a known
plaintext. If we use the 4 round DES, with PRNG generated round keys,
how many different round keys can produce that plaintext/ciphertext
pair? If it's a balanced 64 bit block, and we are using DT, how many
different transpositions can produce that plaintext/ciphertext pair?
Assuming that when doing DT, we transposed twice (for the purpose of
hiding the keystream), how many different keystream strings could have
produced the transposition that created that plaintext/ciphertext pair?
Your assertion that DT can be equalled by 4 round DES is handwaving.
I'd like to see some justification. Prove that 4 round DES with PRNG
generated round keys does a better job of hiding the keystream than DT.
> And this is why I raised the subject of _perfect_ bit-balancing
> conversions, so as to allow DT to be multi-ciphered with substitution
> systems, so it _can_ make a contribution by means of its different
> algebraic structure.
To say "to allow DT to be multi-ciphered with substitution systems,"
doesn't seem to make sense... it's like saying "to allow DES rounds to
be multi-enciphered with Blowfish rounds" or some such. DT is a cipher.
You could use it as a component in a larger system (as DES is a
component in 3DES, and various forms of fenced DES), but mixing DT with
something else makes it cease to be DT, and may make it cease to have
some of the more important mathematical properties DT has.
--
Most scientific innovations do not begin with "Eureka!" They begin with
"That's odd. I wonder why that happened?"
------------------------------
From: "Augusto Jun Devegili" <[EMAIL PROTECTED]>
Subject: Re: Cryptographic Windows APIs or OCX?
Date: Sun, 28 Jan 2001 10:35:32 -0200
Quoted from MSDN Library:
"Secure Channel (S-Channel) is a security service provider module that
implements the popular public key security protocols between Web clients and
servers. These include SSL, PCT, and TLS (an upcoming standard that merges
SSL and PCT). S-Channel is layered on top of CryptoAPI for key and
certificate management services. Independent software vendors and developers
can use S-Channel to add these cryptographic protocols to any client/server
application."
If you don't have access to MSDN Library, I strongly suggest you to buy it.
Plenty of useful documentation.
HTH,
Augusto
------------------------------
From: [EMAIL PROTECTED] (phil hunt)
Crossposted-To: or.politics,talk.politics.crypto,misc.survivalism
Subject: Re: Why Microsoft's Product Activation Stinks
Date: Sun, 28 Jan 2001 14:33:21 +0000
On Sun, 28 Jan 2001 01:23:16 -0800, Anthony Stephen Szopa <[EMAIL PROTECTED]> wrote:
>
>I always appreciate your replies but I see no way around this:
>MS products perform.
MS products perform their intended function very well. Their
intended function is to separate punters from their money.
Unfortunately, their products are not so good when viewed as
computer software. Consider MS recently had 2 24 hour outages due
to inadequacies in IIS and NT. Or consider Netcraft's
(www.netcraft.co.uk) list of the websites with the most uptime --
94% ran Apache, 0% ran IIS or NT.
Note that BillyShit want to persuade their
victi^H^H^H^H^Hcustomers to sign up for the .NET initiative --
where their files will be stored on the oh-so-reliable BillyShit
server. Somehow I think some of them will choose not to take up
this inviting offer.
--
*****[ Phil Hunt ***** [EMAIL PROTECTED] ]*****
"An unforseen issue has arisen with your computer. Don't worry your
silly little head about what has gone wrong; here's a pretty animation
of a paperclip to look at instead." -- Windows2007 error message
------------------------------
From: [EMAIL PROTECTED] (phil hunt)
Crossposted-To: or.politics,talk.politics.crypto,misc.survivalism
Subject: Re: Why Microsoft's Product Activation Stinks
Date: Sun, 28 Jan 2001 15:19:00 +0000
On Sun, 28 Jan 2001 14:33:21 +0000, phil hunt <[EMAIL PROTECTED]> wrote:
>On Sun, 28 Jan 2001 01:23:16 -0800, Anthony Stephen Szopa <[EMAIL PROTECTED]> wrote:
>>
>>I always appreciate your replies but I see no way around this:
>>MS products perform.
>
>MS products perform their intended function very well. Their
>intended function is to separate punters from their money.
>
>Unfortunately, their products are not so good when viewed as
>computer software. Consider MS recently had 2 24 hour outages due
>to inadequacies in IIS and NT. Or consider Netcraft's
>(www.netcraft.co.uk) list of the websites with the most uptime --
>94% ran Apache, 0% ran IIS or NT.
I forget to mention here that MS are now running Linux on some of their
DNS servers, according to some reports. Apparently the MS DNS system
wasn't up to the job.
--
*****[ Phil Hunt ***** [EMAIL PROTECTED] ]*****
"An unforseen issue has arisen with your computer. Don't worry your
silly little head about what has gone wrong; here's a pretty animation
of a paperclip to look at instead." -- Windows2007 error message
------------------------------
From: Rex Stewart <[EMAIL PROTECTED]>
Subject: Re: How many bits of security can a password give?
Date: Sun, 28 Jan 2001 16:54:16 GMT
Arrrg! Nice catch. Of course that should have
been 6.4*(n-1)*5)bits and (n*6.4)bits respectively.
Substantial synapse lapses.
Basically I find that brute forcing one character while
trying to work all the others saves some work when using
complex rule based attacks. This accounts for the 6.4 at
the beginning of the formula.
I have found unless you specifically tell the user
which characters are allowed, it is a rare user who
will inlcude things like a quote or question mark
in their password.
If storage were cheaper, precomputation would be the
way to go. For attacks that are going to be repeated
often that would also be the way to go.
In all else, we are in complete agreement.
In article <94vhv4$fs7$[EMAIL PROTECTED]>,
Splaat23 <[EMAIL PROTECTED]> wrote:
> Those work factors look not right. Ideal passwords (i.e. random ones)
> have exponential work in 'n', not polynomial. I could be wrong,
though.
>
> You are definately right, however, about most passwords being less
than
> ideal. As I see it, each ASCII byte only has 95 different
possiblities,
> including symbols. That's only 6.56 bits per byte of entropy. But even
> that's far off for most password, even random looking passwords. A
> random password that has the full 6.56 bits of entropy would need 2-3
> symbols. Most random looking passwords use only one. So even random
> looking passwords, unless truly generated with every element equally
> likely, will have < 6.56 bits per byte.
>
> Now, non-random passwords have far less entropy. Most have a word or
> two, which, in English, means 1.3-1.7 bits per byte with no
> capitalization, plus <1 bit with capitalization (most will capitalize
> first letter).
>
> All of these attacks, especially ones that use rule-based trial
> generation, can be sped up with offline precomputation of guesses,
> which is a parallelizable op anyway. Storage would be mean (6 TBs for
> all 8 byte ASCII passwords), but not impossible.
>
> Moral: 8 byte passwords are not sufficient to protect against offline
> attacks. Use longer passwords. Or use hiding techniques that can not
be
> offline verified by an attacker.
>
> - Andrew
>
> In article <94vg0l$ec9$[EMAIL PROTECTED]>,
> Rex Stewart <[EMAIL PROTECTED]> wrote:
> > In article <94nd0c$o0m$[EMAIL PROTECTED]>,
> > Splaat23 <[EMAIL PROTECTED]> wrote:
> > > In your crypto class you learn[ed] that entropy is the
> > > measure of randomness. Tom is just making sure you know
> > > that the familiar log2((num of possibilities) ^ (num of elements))
> > > formula only applies when all possibilities are equally likely.
> > >
> > > But you are right, entropy is more commonly discussed
> > > when something has entropy _less than_ what might
> > > be expected. For example: log2(26^8) = 8 * log(26)
> > > is the entropy of a random lowercase password,
> > > but 8*1.3 is the [generally accepted, to within
> > > a margin of error] number of bits of entropy of English.
> > >
> > > - Andrew
> > <snip>>
> >
> > I have found, in the real world, passphrazes tend to be somewhat
> > less than ideal. Even with trained and motivated users (ignoring
> > the ones who are unbelievers) I have devised algorythms that will
> > extract a passphrase with considerably less effort than what the
> > user would expect. Using upper and lower case, numbers and
> > special characters in passphrazes between 8 and 14 characters
> > (the standard advice given nowadays for networks) I found
> > most user passphrazes could be extracted with
> > about 6.4*(n-1*5)^2) work, rather than the (n^6.4)^2 work
> > the users would hope for. Using a rule based
> > attack (for instance, if the previous two characters
> > are uppercase/numeric then this one is likely to also be
> > uppercase/numeric also) that imitates how humans remember
> > things provides a great deal of leverage. I am sure the
> > attacks could be refined even further - but I ran into
> > problems with slowing the attack down because it took
> > to long to compute the next guess.
> >
> > --
> > Rex Stewart
> > PGP Print 9526288F3D0C292D 783D3AB640C2416A
> >
> > Sent via Deja.com
> > http://www.deja.com/
> >
>
> Sent via Deja.com
> http://www.deja.com/
>
--
Rex Stewart
PGP Print 9526288F3D0C292D 783D3AB640C2416A
Sent via Deja.com
http://www.deja.com/
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Dynamic Transposition Revisited (long)
Date: Sun, 28 Jan 2001 19:02:54 +0100
Benjamin Goldberg wrote:
>
> John Savard wrote:
[snip]
> To say "to allow DT to be multi-ciphered with substitution systems,"
> doesn't seem to make sense... it's like saying "to allow DES rounds to
> be multi-enciphered with Blowfish rounds" or some such. DT is a cipher.
> You could use it as a component in a larger system (as DES is a
> component in 3DES, and various forms of fenced DES), but mixing DT with
> something else makes it cease to be DT, and may make it cease to have
> some of the more important mathematical properties DT has.
It could be due to my foreigner's English understanding,
but I understand that John Savard means that his effort
is to enable the technique underlying DT (the basic ideas)
to be combined with other encryption techniques to achieve
better strength. That hereby, through modification/adaptation,
the exact 'orginal' DT is no longer present (in the narrow
sense) is clear. But this isn't essential, excepting from a
historical point of view, I suppose.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Dynamic Transposition Revisited (long)
Date: Sun, 28 Jan 2001 18:22:26 GMT
On Sun, 28 Jan 2001 13:10:28 GMT, Benjamin Goldberg
<[EMAIL PROTECTED]> wrote, in part:
>We don't need to produce all possible *codebooks*, just all possible
>*codes*. You seem to want:
> ForEach k ( k is a key )
> DT_k produces one of (N!/(N/2!)(N/2!))! substitutions.
actually,
ForEach S (S is any one of (N!/((N/2)!(N/2)!))! substitutions
ThereExists a key k such that DT_k produces S
just to be completely accurate and produce no confusion
>This is indeed something which DT does NOT do. However, it's not
>needed. We just need for any input code to be able to produce any of
>the possible output codes, given an appropriate key.
You're close, but this isn't exactly what I'm saying. You are right
that "it's not needed" that Dynamic Transposition do this.
But, equally, it isn't needed that a substitution-based cipher do this
either.
Since Mr. Ritter appears to me to be saying that a cipher, based on
using DES with subkeys supplied by a stream cipher, is inadequate, and
inferior to Dynamic Transposition, *precisely because* DES cannot
produce all possible codebooks, my point is not that Dynamic
Transposition is _also_ inadequate, but rather that the claim that
Dynamic Transposition is inherently greatly superior is mistaken.
Neither cipher produces all possible codebooks; both ciphers produce
any possible output - with many different keys for each output - for
each given input.
"All possible transpositions" may be nice, but it doesn't buy you the
kind of important advantages that appear to be being claimed.
However, thank you for reminding me about a post I made a while back,
which generated intense controversy. In that post, I noted that the
properties of Galois Fields were such that if instead of applying a
keystream via XOR, I applied two keystreams, one by XOR, and the other
- composed of nonzero values only - by Galois Field multiplication, I
could obtain the situation where:
For any plaintext block P,
not only may I obtain multiple substitutions in which the cipher block
is Q,
but I can obtain a substitution in which P -> Q
and also P' -> Q'
for any P' <> P and any Q' <> Q.
I was excoriated by several of the genuine cryptographic experts in
this newsgroup for daring to suggest this property - which provided
resistance against the bit-flipping attack - was significant or
useful. Use ciphers to encrypt, and hash functions and signatures to
authenticate! Well, I wasn't disputing that that was sound practice, I
was merely giving what I thought was the simplest possible example
that illustrated the importance of Galois Fields in cryptography.
Anyhow, Dynamic Transposition doesn't even have this property.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
** 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 by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
