Cryptography-Digest Digest #595
Cryptography-Digest Digest #595, Volume #13 Wed, 31 Jan 01 02:13:00 EST
Contents:
Re: Why Microsoft's Product Activation Stinks ("David Thompson")
Re: Differential Analysis ("David Thompson")
Re: On combining permutations and substitutions in encryption (Terry Ritter)
Re: Free Encryption Software ("George Peters")
Re: On combining permutations and substitutions in encryption (Terry Ritter)
Re: On combining permutations and substitutions in encryption (Terry Ritter)
Re: What do you do with broken crypto hardware? (Paul Rubin)
Re: Windows encryption: API and file system ("Douglas A. Gwyn")
Re: MIKE - alternative to SPEKE and PAK ("Michael Scott")
Shared key protocols ([EMAIL PROTECTED])
Re: Ciphertext Stealing question (John Savard)
More About Passwords (John Savard)
Re: Free Encryption Software (Splaat23)
Re: Algorithm M question (Benjamin Goldberg)
From: "David Thompson" <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: Why Microsoft's Product Activation Stinks
Date: Wed, 31 Jan 2001 04:40:46 GMT
(groups trimmed)
Richard Heathfield <[EMAIL PROTECTED]> wrote :
> [Sorry to reply to Joe's post when I'm really addressing the issues
> raised by Mr Szopa. Mr Szopa's article hasn't hit my newsfeed yet and
> may not do so for some time...]
>
Any ideas how the rest of us could get that to happen?
--
- David.Thompson 1 now at worldnet.att.net
--
From: "David Thompson" <[EMAIL PROTECTED]>
Subject: Re: Differential Analysis
Date: Wed, 31 Jan 2001 04:41:34 GMT
Benjamin Goldberg <[EMAIL PROTECTED]> wrote :
> David Thompson wrote:
...
> > ++table[x^y][sbox[x]^sbox[y]]
> > if x and y are the two inputs, or
> > ++table[x][sbox[y]^sbox[y^x]]
> > if y is one input and x the input difference.
> > This is not the same as either your code
> > or Benjamin's as posted.
>
> Actually, I did have it right...
> See:
...
> > ++table[x][sbox[x]^sbox[x^y]];
...
No, my second has sbox[y]. x is the difference
and y is an input. Your line tries to treat x
as both the difference and an input.
PS- Though in the source code (if ASCII)
there is only 1 bit difference. ('x' ^ 'y') == 1.
--
- David.Thompson 1 now at worldnet.att.net
--
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: On combining permutations and substitutions in encryption
Date: Wed, 31 Jan 2001 04:49:09 GMT
On Tue, 30 Jan 2001 06:32:39 GMT, in
, in sci.crypt "Matt
Timmermans" <[EMAIL PROTECTED]> wrote:
>"Terry Ritter" <[EMAIL PROTECTED]> wrote in message
>news:[EMAIL PROTECTED]...
>> Really? Well, here is my first paragraph again, unchanged:
>> [...]
>> So, exactly what about the idea of addressing "currently-known and
>> most-likely" attacks sounds to you like "*any* attack"?
>
>Nothing at all. Your first paragraph, I conceded immediately. That's not
>the idea I quoted.
>
>I quoted this:
>
>> >"Terry Ritter" <[EMAIL PROTECTED]> wrote in message
>> >news:[EMAIL PROTECTED]...
>> >> The obvious attack is on the RNG keyspace, the internal state. But we
>> >> can easily make ciphers with hundreds of thousands of bits of internal
>> >> state, which is far more than "large enough." When we do, we at least
>> >> have the opportunity of proving that any attack on the keyspace must
>> >> be impractical. There is nothing unreasonable about this.
>
>and was referring to the part where you explicitly said "any attack". You
>meant "any attack against the internal state",
That paragraph specifically refers to brute-force attacks on the
keyspace. That would include any attempt to simply step through the
internal state, along with any attempt to step through all possible
keys. It would not include, for example, some sort of interactive
chosen-RNG-state attack, where the output results influence the next
choice of RNG state. On the other hand, there might be something we
could say about that as well.
>and so did I:
>
>> , in sci.crypt "Matt
>> Timmermans" <[EMAIL PROTECTED]> wrote:
>> >[...]
>> >"Given this pt/ct pair, is it possible that the n'th
>> >bit of the RNG state is a 1"? is in NP if encryption is in P.
>
>And so, if P=NP, any DT cipher with bounded key size can be cracked in
>polynomial time. This is probably not a practical disadvantage, but it
>certainly is a hard barrier to provable security.
The particular issue is impracticality. The goal is to prove "no
non-interactive brute force attack can be practical." The proof
should be obvious.
>> "It is easy to have a prejudice that a cipher cannot be provably
>> secure. The most difficult part of this might be the implicit
>> understanding of "from any possible attack."
>
>"Prejudice" is a belief, and irrelevant, because you do not take *provable*
>security on faith -- you take it on proof. Please provide one.
Uh, how about "the state space is large enough.
Cryptography-Digest Digest #594
Cryptography-Digest Digest #594, Volume #13 Tue, 30 Jan 01 23:13:01 EST
Contents:
Re: Ciphertext Stealing question (Jerry Maple)
Re: A Password Protocol (John Savard)
Re: fast signing ("Joseph Ashwood")
Free Encryption Software ("George Peters")
Re: MIKE - alternative to SPEKE and PAK ("Michael Scott")
Algorithm M question (Benjamin Goldberg)
AES and randomness (JCA)
Re: fast signing (Paul Rubin)
Re: Algorithm M question (John Savard)
Re: Very short redundant serial number (Darren New)
Re: fast signing (Bob Silverman)
Re: AES and randomness (Splaat23)
Re: fast signing ("Joseph Ashwood")
Re: fast signing (Splaat23)
Re: Free Encryption Software (Splaat23)
Re: fast signing (Paul Rubin)
Re: MIKE - alternative to SPEKE and PAK (Thomas Wu)
Re: Algorithm M question (Terry Ritter)
Re: Ciphertext Stealing question (Benjamin Goldberg)
Re: AES and randomness ("Scott Fluhrer")
Re: Ciphertext Stealing question ("Scott Fluhrer")
Re: Algorithm M question (Benjamin Goldberg)
From: [EMAIL PROTECTED] (Jerry Maple)
Subject: Re: Ciphertext Stealing question
Date: 30 Jan 2001 22:51:47 GMT
Jim Gillogly <[EMAIL PROTECTED]> wrote in <[EMAIL PROTECTED]>:
>I know there are a lot of assumptions there, and as Samuel L. Jackson's
>character said in "The Long Kiss Goodnight", when you make an assumption
>you make an ass out of u and mption.
I'm a long-time lurker, this quote brought me out of the shadows.
Paraphrase of one of my favorite quotes. I believe Benny Hill predates
this - his German professor character, as he stands at the chalkboard
writing:
"When you _assume_, you make an _ass_ out of _u_ and _me_!"
Jerry
--
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: A Password Protocol
Date: Tue, 30 Jan 2001 22:47:56 GMT
On Tue, 30 Jan 2001 21:45:36 +, David Hopwood
<[EMAIL PROTECTED]> wrote, in part:
>For each guessed password, an attacker can repeat these steps (using
>an eavesdropped challenge vector), until the transmitted hash matches.
>Therefore the protocol is vulnerable to off-line password guessing
>attacks.
As noted, I was aware of this, and did not attempt to address this
particular attack here.
Earlier, I had been thinking of a protocol with this type of security,
making use of EKE techniques, but it had the flaw that the connection
between the host and the machine I call the 'security computer' had to
be relied upon. So I was thinking in the other direction here.
I will shortly sit down and think if the kind of technique I'm looking
at here can be combined with ways to avoid reliance on the user's
(likely guessable) password.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
--
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: fast signing
Date: Tue, 30 Jan 2001 15:18:06 -0800
"Paul Rubin" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> "Joseph Ashwood" <[EMAIL PROTECTED]> writes:
> > Ok to clarify:
> > I need signing to by excessively fast. I've got an application where one
> > person here expects in the 10,000 signature/second range (I doubt he'll
get
> > that speed out of his code, but that's another issue), on a
single-processor
> > x86 P4 1.5 GHz, gobs of RAM, etc.
>
> There's no way to do that many sigs/sec on that hardware on a
> continuous basis with any public key algorithm that I know of.
Yeah I'm very familiar with the problem. I've even looked at using MACs but
can't find one that fits into the threat model correctly.
> The
> way to secure audit logs is with hash chains, not public key
> signatures. See:
Unfortunately hash chains are simply not strong enough in the model I have
to work with, they have a tendancy where if one breaks, all future ones are
broken and that is unacceptable. Additionally the quoted paper is of even
less use in this case because it is a requirement that the admin be able to
read the audit log with a text editor. Not my rules, just the rules I have
to work in. Additionally you may want to look at the last sentence of that
paper, it might dissuade you from looking at it in the same light, a quick
hint it includes the words "patent pending". I am however examining
alternatives, trying to build something security-equivalent (or superior)
without it being patent-equivalent, but that's a different project.
> You might be able to do a DSA signature in 0.1 msec (1/10,000 sec) on
> that P4 with several msec of precomputation per signature, i.e. if
> you're going to have 10,000 documents to sign tomorrow, you could
> spend several hours doing precomputation today and then do all 10,000
> signatures in 1 sec, but I don't know if that helps you.
Honestly, I wish it did. I'd been thinking along the same lines, but the
usage model right now dictates, 100K/sec sustained for long periods of time.
I almost laughed at the guy when he said that. I've seen additio
Cryptography-Digest Digest #593
Cryptography-Digest Digest #593, Volume #13 Tue, 30 Jan 01 18:13:00 EST
Contents:
Re: Random stream testing. (long) ("Paul Pires")
Re: How many bits of security can a password give? (Splaat23)
Re: Ciphertext Stealing question (Paul Rubin)
Re: Recommendations on simplest way to add client/server encryption ("Joseph
Ashwood")
I need some crypting components for Delphi! ("ddd")
Re: fast signing (Bob Silverman)
Re: A Password Protocol (David Hopwood)
Re: fast signing ("Joseph Ashwood")
Re: Ciphertext Stealing question (Jim Gillogly)
Re: Ciphertext Stealing question ("Joseph Ashwood")
Re: fast signing (Paul Rubin)
Re: fast signing (Paul Rubin)
Re: I need some crypting components for Delphi! ([EMAIL PROTECTED])
From: "Paul Pires" <[EMAIL PROTECTED]>
Crossposted-To: sci.crypt.random-numbers
Subject: Re: Random stream testing. (long)
Date: Tue, 30 Jan 2001 13:22:22 -0800
Joseph Ashwood <[EMAIL PROTECTED]> wrote in message news:OPsaMv#hAHA.319@cpmsnbbsa09...
>
> "Paul Pires" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > Joseph Ashwood <[EMAIL PROTECTED]> wrote in message
> >
> > > Well RNG output has 1 bit of entropy per bit, (Deterministic)PRNG output
> > has
> > > a fixed k bits of entropy scattered throughout the infinite output
> > (although
> > > the entropy in a given bit is likely to diminish to true 0 near the end
> > > versus near the beginning).
> > Is there any test that detects this difference in blind data? I believe
> that
> > you
> > said no but I just wanted to verify.
>
> Such a program can't exist, a program could however be created that gave an
> apparent entropy value, but not a measurement of real entropy.
>
>
> > Did you folks run any data collected from some true random source as a
> > control? Did it perform similarly to PRNG's as far as "passing your
> > criteria"
> > goes? I have found that it is real hard to raise the bar just high enough
> > so
> > that there is a distinction between otherwise "Good" generators. Maybe it
> > is not possible but I still have some subborn pig-headed bumbling about to
> > do before I stop looking.
>
> Well we ran into a very hard problem, in order to verify the test suite we
> would have had to find a perfect true RNG, and that requires a mathematic
> proof for verification, so we actually couldn't (although we did do a
> smaller test on a bunch of dice where the dice actually failed, I suspect
> it's because of the bias in them, or because the suite was too small). If it
> didn't have a solid proof behind it then we ran the risk of verifying
> correctness against an incorrect benchmark.
> Joe
Sorry for the tardy reply, My server is acting senile again :-)
A proof of correctness would be great but I'd be happy to get
a handle on improving the discretion of tests. Right now, there
seems to be a knee in the curve. After a certain point is reached,
everything looks pretty darn good. What I have been looking into
is quantifying different tests against each other to see which ones
should trend alike and which ones seem un-correlated for same
data sets. My hope is to spot some inter-relationship that is more
sensitive to "Goodness" rather than looking for a "good/bad" score.
All I have found so far is a correlation between the Entropy test
[Hamming, pp. 104-108] as implemented in The test suite "ent"
and the Chi-square Test as implemented in the same package.
For a large result set, Chop, baseline shift, invert about the baseline
and scale and the two result sets graph over each other. Seems like
the only difference when looking at data sets is in the round-off error.
Unfortunately, I haven't found a practical use for this particular insight.
It probably means that at some basic level that these are the same
analysis looking a the same samples within each data file. They just
present the answer in a different way.
About the only thing I add to the effort is ant-like persistence. I test,
check, modify and observe and hope (like a kid with a chemistry set)
to spot something interesting. I tried thinking and it hurt. I am now
reduced to pokin around.
Thanks for the help,
Paul
== Posted via Newsfeeds.Com, Uncensored Usenet News ==
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
=== Over 80,000 Newsgroups = 16 Different Servers! ==
--
From: Splaat23 <[EMAIL PROTECTED]>
Subject: Re: How many bits of security can a password give?
Date: Tue, 30 Jan 2001 21:15:19 GMT
Umm, 8 random bytes = 64 random bits = 64 bits of entropy/"security".
There are 256^8 = (2^8)^8 = 2^64 different passwords with 8 random
bytes.
- Andrew
In article <95743r$ivp$[EMAIL PROTECTED]>,
Simon Johnson <[EMAIL PROTECTED]> wrote:
> In article <94mn7a$27r$[EMAIL PROTECTED]>,
> Erik Runeson <[EMAIL PROTECTED]> wrote:
> > I'm doing some analysis on how many
Cryptography-Digest Digest #592
Cryptography-Digest Digest #592, Volume #13 Tue, 30 Jan 01 16:13:01 EST
Contents:
Re: fast signing (Gerard Tel)
Re: How many bits of security can a password give? (Rex Stewart)
Re: Dynamic Transposition Revisited (long) (John Savard)
Re: Dynamic Transposition Revisited (long) (John Savard)
Re: Recommendations on simplest way to add client/server encryption (Rob Yampolsky)
Re: "Enigma" at Sundance ("*")
Re: fast signing (DJohn37050)
Re: Recommendations on simplest way to add client/server encryption (Bernd Eckenfels)
Re: Recommendations on simplest way to add client/server encryption (Angry Bob)
Re: Why Microsoft's Product Activation Stinks (Richard Herring)
Re: test (Dido Sevilla)
Re: How many bits of security can a password give? (Splaat23)
Re: MIKE - alternative to SPEKE and PAK ("Michael Scott")
Re: Echelon in Asia. (John Hairell)
Ciphertext Stealing question ("N. Weicher")
Re: How many bits of security can a password give? (Simon Johnson)
Re: Why Microsoft's Product Activation Stinks (AllanW)
crypto algoritm or program ("Bteee")
From: Gerard Tel <[EMAIL PROTECTED]>
Subject: Re: fast signing
Date: Tue, 30 Jan 2001 16:07:23 +0100
Bob Silverman wrote:
>
> In article ,
> > What is the fastest secure signing algorithm?
> Note that RSA with e = 3 takes only 2 modular multiplies.
But that is for signature verification.
Signing uses the secret exponent d, which is NOT short.
Gerard Tel
http://www.cs.uu.nl/~gerard/
--
From: Rex Stewart <[EMAIL PROTECTED]>
Subject: Re: How many bits of security can a password give?
Date: Tue, 30 Jan 2001 15:27:04 GMT
In article,"Joseph Ashwood" <[EMAIL PROTECTED]> wrote:
what I was going to make is an estimate of
> which letters should be expected in which
> frequency. While this is a different quantity
> from entropy, it will approximate it. This was just to
> get a rough estimate of the entropy per character
> of the use the first letter of each word. I wouldn't
> dream of making a dictionary for such a thing, it would
> require some interesting girations to get working correctly.
> Joe
>
You're on the right track - or at least the same path
I followed with my work. However, don't use RFC's.
Real people don't talk like RFC's. There are plenty
of web pages filled with literature, and that is how
the average person is going to think. If you catalouge
the first or last letters of words, there is a slight
difference - but if you catalouge the second letters - you
will see a striking shift. (OTOH, people find the second
or last letters much more difficult at first - and so
never get around to being that sophisticated.)
--
Rex Stewart
PGP Print 9526288F3D0C292D 783D3AB640C2416A
Sent via Deja.com
http://www.deja.com/
--
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Dynamic Transposition Revisited (long)
Date: Tue, 30 Jan 2001 15:29:30 GMT
On 30 Jan 2001 12:24:29 GMT, [EMAIL PROTECTED] (Rob Warnock)
wrote, in part:
>And the HIPPI-Serial standard requires that, actually. But it's not
>to "maintain balance" -- since if one has a completely balanced input
>string, well, one has a completely balanced input string! -- but to
>provide a guaranteed bit transition at frame edges for preserving
>clocking and frame synchronization.
Yes, but one does not have a completely balanced *output* string if it
consists of every block of the input string *preceded by a 0*.
And, since the bit indicating inversion is the first bit of each
frame, I don't see how inverting every second block provides a
guaranteed bit transition anyways.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
--
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Dynamic Transposition Revisited (long)
Date: Tue, 30 Jan 2001 15:32:25 GMT
On 30 Jan 2001 12:34:44 GMT, [EMAIL PROTECTED] (Rob Warnock)
wrote, in part:
>Exactly so. But removing the D.C. component creates its own problems,
>such as the so-called "baseline drift" that occurs when the D.C. component
>is removed with a simple series capacitor.
The point of "removing the D.C. component" _by means of modulation_ is
precisely to avoid baseline drift, since DC components tend to get
lost in ordinary types of circuitry. If I had meant throwing away
important information from the signal...
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
--
From: Rob Yampolsky <[EMAIL PROTECTED]>
Crossposted-To: comp.security.misc
Subject: Re: Recommendations on simplest way to add client/server encryption
Date: Tue, 30 Jan 2001 11:12:34 -0500
This will be my last question - maybe...
Your pseudo code seems to bypass the SSL handshake completely, substituting a
similar manual one. I'm guessing that what this really saves me is having to
set up a certificate authority. In my initial (unencrypted) handshake,
Cryptography-Digest Digest #591
Cryptography-Digest Digest #591, Volume #13 Tue, 30 Jan 01 10:13:01 EST
Contents:
Re: A Password Protocol (John Savard)
Re: Why Microsoft's Product Activation Stinks (wtshaw)
Re: Windows encryption: API and file system (wtshaw)
Re: Security of Centrinity's FirstClass Product ([EMAIL PROTECTED])
Re: random number generators. Can someone help? (Mok-Kong Shen)
Re: On combining permutations and substitutions in encryption (Mok-Kong Shen)
Re: fast signing (Paul Rubin)
test ([EMAIL PROTECTED])
Re: Dynamic Transposition Revisited (long) (Rob Warnock)
Re: Dynamic Transposition Revisited (long) (Rob Warnock)
News: Szopa Goes E-Postal. Plus, I.T. Industry faces FUD Clean Up? (Lord Running
Clam)
Re: fast signing (Mehdi-Laurent Akkar)
Re: test (Mehdi-Laurent Akkar)
Re: fast signing (Bob Silverman)
Re: Primality Test (Bob Silverman)
Re: Primality Test (Bob Silverman)
Re: cryptographic tourism in Russia ("Rodney Perkins")
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: A Password Protocol
Date: Tue, 30 Jan 2001 07:01:07 GMT
On Tue, 30 Jan 2001 03:38:51 GMT, Benjamin Goldberg
<[EMAIL PROTECTED]> wrote, in part:
>Given the scenario requirements, it seems quite obvious that the best
>thing to be using is Kerberos. Do a google search, and you'll get lots
>of decent descriptions.
Actually, you'll find one on my web site.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
--
From: [EMAIL PROTECTED] (wtshaw)
Crossposted-To: or.politics,talk.politics.crypto,misc.survivalism
Subject: Re: Why Microsoft's Product Activation Stinks
Date: Tue, 30 Jan 2001 00:45:27 -0600
In article <[EMAIL PROTECTED]>, Anthony Stephen Szopa
<[EMAIL PROTECTED]> wrote:
>
> Bill Gates is worth nearly a hundred billion dollars and you can say
> things are not settled yet.
>
> Ha ha ha.
Court cases...
--
Some people say what they think will impress you, but ultimately
do as they please. If their past shows this, don't expect a change.
--
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Windows encryption: API and file system
Date: Tue, 30 Jan 2001 00:43:26 -0600
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> NT is not a problem if the alternative is Windows9x! ... and the
> original poster did ask about *Windows* encryption.
>
Neither is acceptable.
--
Some people say what they think will impress you, but ultimately
do as they please. If their past shows this, don't expect a change.
--
From: [EMAIL PROTECTED]
Subject: Re: Security of Centrinity's FirstClass Product
Date: Tue, 30 Jan 2001 07:36:37 GMT
Thanks guys... I think I get a better idea now
GW
Sent via Deja.com
http://www.deja.com/
--
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: random number generators. Can someone help?
Date: Tue, 30 Jan 2001 10:31:47 +0100
[EMAIL PROTECTED] wrote:
>
> Sorry to bother. I don't know if there is a more appropriate NG for my
> question or not. I was wondering if there is a web-site that will allow
> you to program simple random # routines without actually
> programming/without having to do any downloading, out there? I figure
> someone must have thought of this idea, before me, and since most people
> are less lazy, and have more resources available, I would guess that
> someone has done it. If there isn't now was there ever one? Is there a
> better NG (or elist, etc.)for me to be asking this qwuestion @?
With the least effort: Your programming language or the
operating system normally has a PRNG ready. If you are
in a scientific computing environment: There are PRNGs
in numerical libraries, e.g. NAG, IMSL, that you can
include and use in your programs. Otherwise, for code:
Press et al., Numerical Recipes; for theory: Knuth,
The Art of Computer Programming, Vol.2. For testing
of random numbers: http://csrc.nist.gov/rng/ The NG is:
sci.crypt.random-numbers.
M. K. Shen
http://home.t-online.de/home/mok-kong.shen
--
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: On combining permutations and substitutions in encryption
Date: Tue, 30 Jan 2001 11:24:12 +0100
Terry Ritter wrote:
>
[snip]
> Since some RNG information is hidden by the advanced combiner, the
> issue of whether *all* relevant information can be hidden is more than
> some vain hope; it is a reasonable question. A positive example would
> indeed be "absolutely" unbreakable for attacks from the ciphertext
> channel, but not necessarily unbreakable for unlimited computation.
> This is not weird science.
>
> An RNG is only predictable when we know enough about it. While we
> cannot expect to create unpredictability by computation, we might well
> hope to achieve the inability to exploit the predictability we know is
> there.
>
> I am unaware of any pr
