Cryptography-Digest Digest #220, Volume #12 Thu, 13 Jul 00 14:13:02 EDT
Contents:
Re: Chaining mode discussion (Runu Knips)
Re: Bit Shuffling ("Adam Durana")
Re: Quantum Computer similator websites with source code (Jamie Andrews)
Re: Diffie Hellman Primes : Speed Tradeoff Q (Mark Wooding)
Re: Proposal of some processor instructions for cryptographical (Paul Koning)
Re: New Idea - Cipher on a Disk ("Trevor L. Jackson, III")
Re: Diffie Hellman Primes : Speed Tradeoff Q (DJohn37050)
Re: New Idea - Cipher on a Disk ("Trevor L. Jackson, III")
Re: General Question on cryptography ("Trevor L. Jackson, III")
Re: Base Encryption: Strongest Cypher (S. T. L.)
Random numbers and online-gambling ([EMAIL PROTECTED])
Perl routines for vigenere cipher? ([EMAIL PROTECTED])
Re: New Idea - Cipher on a Disk (Chris T)
Re: Diffie Hellman Primes : Speed Tradeoff Q (Mark Wooding)
Re: Proposal of some processor instructions for cryptographical applications
(Jan Vorbrueggen)
Re: Using CRC's to pre-process keys (David A. Wagner)
Re: Enigma Variations ("Wesley H. Horton")
Re: Diffie Hellman Primes : Speed Tradeoff Q (Bob Silverman)
Re: Diffie Hellman Primes : Speed Tradeoff Q (Bob Silverman)
Re: Diffie Hellman Primes : Speed Tradeoff Q (DJohn37050)
----------------------------------------------------------------------------
Date: Thu, 13 Jul 2000 16:08:01 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: Chaining mode discussion
Mark Wooding wrote:
> Yes, we *might* get a collision well before the 2^{n/2} threshold, but
> it's not very likely. The attacker *might* just guess the right key on
> his third guess.
I think it is far more probable that such a collision appears, compared
to the probability that the attacker guesses a carefully selected 128
(or more) bit key. Okay, of course the damage from such a collision is
also far less dangerous than the correct guess of the key.
> We're only worried when collisions start to become
> *probable*. And this problem is well known. See, for example, `A
> concrete security treatment of symmetric encryption: Analysis of the DES
> modes of operation' by Mihir Bellare, Anand Desai, Eron Jokipii and
> Phillip Rogaway, which provides tight security bounds on the security of
> CBC mode.
Thank you for that link.
> > Its really a bad and principial property, and I think one should use
> > a different chaining mode to get rid of it.
>
> I think that your response is due to a misunderstanding about the
> significance and novelty of Vaudenay's result.
Well, this principial weakness of CBC is simply against my sense
of aesthetics ;-)
------------------------------
From: "Adam Durana" <[EMAIL PROTECTED]>
Subject: Re: Bit Shuffling
Date: Thu, 13 Jul 2000 10:43:24 -0400
> Hi,
>
> I know this function is linear and it is not meant to be
> a complete cipher in itself. It is meant to be used
If you've studied it at all you'd know that even as a component of a cipher,
it still exhibits bad qualities.
> for creating diffusion, and you need to have another
> function for confusion. Regarding the rip off, the
> patent application was filed in mid 1998, significantly
> before early 1999. Please be a bit more careful when you
> issue such strong statements.
I'm sure if I had said 98, your patent would have been filed in 97.
>
> best regards,
> Jayant
And it looks like someone else has posted that this idea was presented long
before 98. So it looks like you are out of luck with your patent.
------------------------------
From: [EMAIL PROTECTED] (Jamie Andrews)
Crossposted-To: comp.theory
Subject: Re: Quantum Computer similator websites with source code
Date: 13 Jul 2000 14:51:33 GMT
Jeff Erickson wrote:
>Hardly. Given the recent computation of the trillionth(!) bit of pi
>using classical computers, why should anyone think computing bits of
>sqrt(2+x) is hard?
Absolutely. Heck, I can compute the millionth bit of
sqrt(2+x) in my head... for x of the form (n*n - 2).
--Jamie.
andrews .uwo } Merge these two lines to obtain my e-mail address.
@csd .ca } (Unsolicited "bulk" e-mail costs everyone.)
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Diffie Hellman Primes : Speed Tradeoff Q
Date: 13 Jul 2000 15:04:33 GMT
DJohn37050 <[EMAIL PROTECTED]> wrote:
> And look at IEEE P1363 which discusses all this.
Can you be more specific? I've just dug through lots of the P1363
material without turning anything up.
-- [mdw]
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Crossposted-To: comp.arch
Subject: Re: Proposal of some processor instructions for cryptographical
Date: Thu, 13 Jul 2000 10:41:24 -0400
Jan Vorbrueggen wrote:
>
> Paul Koning <[EMAIL PROTECTED]> writes:
>
> > That's why CPU system buses have byte enables.
>
> I don't think the EV6 bus has byte enables.
The Alpha architecture team had excellent arguments for leaving
out byte load/store from the architecture. Unfortunately,
the rest of the world was unconvinced, and this is one of
the reasons the Alpha was far less successful than it should
have been.
Later on, byte operations were patched into the architecture,
but from what you're saying it appears that support for it
is still incomplete compared to most other architectures.
As a router builder, I'd take a machine with byte write support
all the way out (i.e., byte enables on the sysbus) over one
that doesn't, all else being equal.
paul
------------------------------
Date: Thu, 13 Jul 2000 11:22:25 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: New Idea - Cipher on a Disk
Joseph Ashwood wrote:
> > But the harder problem is getting the key from the user to
> the disk. There's
> > no existing mechanism for this.
>
> Sure there is, use sideband information. Write to a location
> on disk that cannot exist. There must be a maximum address
> on the disk, simply reduce the maximum disk size by one
> block, and "write" to the last block so set the password.
First, writing to a sector isn't really sideband, it's reusing the main band.
Thus it may collide with other special purpose uses of the last block.
Also, "the last block" is rarely well defined. Typically the manufacturer's
bad sector list is written on the last few tracks, and spare tracks (for
dynamic track remapping) are allocated from that end of the drive. Adding
another reserved section to the drive map adds considerable complexity due to
the layers of hard and software that know about the existing special purpose
sections.
I think this concept needs a true sideband channel -- one that extends the
interface between the drive and the world. Such extension is hard to do
transparently.
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Date: 13 Jul 2000 15:16:57 GMT
Subject: Re: Diffie Hellman Primes : Speed Tradeoff Q
small subgroup and lots of other considerations are discussed in the security
annex.
Don Johnson
------------------------------
Date: Thu, 13 Jul 2000 11:37:36 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: New Idea - Cipher on a Disk
Greg wrote:
> The key persists with the HD power and reset.
So the drive knows it's own key? That's a problem. If the drive knows it
then a thief can find it. I'd expect the drive to forget the key every time
it was powered down. And while it was powered up it would need a secure place
to store the key; some place that did not "learn" the key value the way
magnetic media and RAM does.
>
>
> > Bottom line is that I don't think you can implement an encrypting
> > drive as a replacement for an existing non-encrypting drive.
>
> Wrong. It would be a feature that can be used if the controller
> supported it. If not, it is a feature that is not tapped by the
> controller. I think the latest ATA level is 5 now. Imagine an ATA
> level 6 that supports encryption. The disk can be rated ATA6, but
> it works with all levels of ATA to the limit of the ATA level supported
> by the controller card.
Yes, this kind of enhancement is certainly possible. Hard to justify though
given the existence of free packages like PGPdisk and Scramdisk.
There's also the issue of the obsolescence of the encryption hardware. I once
had a machine that was one generation behind the state-of-the-art machine.
The system used disk compression that made it IO bound when it should have
been compute bound, so I invested in an accelerator card for the compression
mechanism. It gave me about a factor of two in performance.
Shortly thereafter I upgraded the machine to the latest and greatest, getting
about an order of magnitude in performance. When I tested the hardware
accelerator against the software driver it slowed the system down by more than
a factor of three. The CPU upgrade had left the hardware compression engine
in the dust. The same could happen to a hardware encryption engine embedded
in a drive. It would be _really_ tough to sell a secure drive that was slower
and more expensive than a bare drive plus free encryption software.
------------------------------
Date: Thu, 13 Jul 2000 11:39:46 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: General Question on cryptography
"S. T. L." wrote:
> <<why can't someone develop a combination of algorithms that no one
> would ever think of>>
>
> The phrase is "security by obscurity". Which means "sucks big time". There
> are FAQs for things like this.
If you rephrase the original concept you'll find it leads to a contradiction:
"Why can't someone think of a combination of algorithms that no one would ever
think of?"
------------------------------
From: [EMAIL PROTECTED] (S. T. L.)
Date: 13 Jul 2000 15:29:27 GMT
Subject: Re: Base Encryption: Strongest Cypher
<<Until then, i'll keep an open mind :)>>
Hot damn, I love having a quotation collection:
"Keeping an open mind is a virtue - but as the space engineer James Oberg once
said, not so open that your brains fall out" - Carl Sagan, The Demon-Haunted
World
"An open mind, like an open window, should be screened to keep the bugs out" -
Virginia Hutchinson
-*---*-------
S.T.L. My Quotes Page * http://quote.cjb.net * leads to my NEW site.
Now **141** reviews of my 169 science books, with ratings as well!
I am now a total PNG convert. Long live pngrewrite and pngcrush!
------------------------------
From: [EMAIL PROTECTED]
Subject: Random numbers and online-gambling
Date: Thu, 13 Jul 2000 15:30:02 GMT
Hi!
Some weeks ago I found a web-page containing
an analysis of an online-poker system. There
was described how the shuffling of the cards
was done and why the chosen approach was not
appropriate for online-gambling. A description of
how to break the game including countermeasures
was given. The report was IIRC about one year old.
As I do not remember in detail the analysis
of the permutation-algorithm and the flaws in
the random number generation, I tried several
search-engines, but with no appropriate results.
If someone has a hint for me where the report
can be found or where I can continue my search,
that would be great!
Thanks for any help,
Michael
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Perl routines for vigenere cipher?
Date: Thu, 13 Jul 2000 15:31:07 GMT
First time posting.
I just started investigating the security of a commercial application
that encodes (and stores) a password using what Is apparently a trivial
cipher? If I can reverse engineer the lgorithm I
can prove my point about the error of "security through obscurity."
I've been using Perl and known cleartext to find the algorithm.
This is my first cryptographic analysis, and it's fun so far, but I
admit that my cryptp background is minimmal.
The ciphertext is limited to the ASCII characters above "space"
(hex 20) to 7F. I have a few examples of known cleartext at this time.
(and two dozen examples of ciphertext).
Length of Cleartext Length of Ciphertext
1 2
2 4
3 5
I am getting more examples of cleartext/plaintext pairs,
(I need the help of a sysadmin for this.)
Does anyone have any tools, preferably in Perl, for investigating
the possible key/algorithm? This is trivial for an expert
(i.e. not me.), and I am hoping someone has some tools and hints
that can help automate the search for the key & algorithm.
Perhaps this isn't a Vigenere, because the length of cleartext
isn't the length of the ciphertext?
What should I be looking for?
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Chris T <[EMAIL PROTECTED]>
Subject: Re: New Idea - Cipher on a Disk
Date: 13 Jul 2000 15:22:37 GMT
Greg wrote:
<
< Let's try this-
<
< - You enter a password into a BIOS startup screen
<
< - the disk creates a key from the password
<
< - if the disk is not currently encrypted, then
< - the disk throws out the key and runs in unencrypted mode
< else
< - the disk takes the key and uses it for all traffic to
< and from the platters
<
< At some point, a user will want to START using encryption.
< To change from unencrypted to encrypted, a command is given
< by the software or BIOS firmware to take a password, create
< a key, and encrypt the entire disk. After this, the disk
< is encrypted. To go back to an unencrypted format, the same
< is done but with a null password. To change encryption keys
< one must decrypt with the old key then encrypt with the new key.
<
< Does that answer your question or did I miss what you were
< getting at?
<
There's one thing that I'm not clear about. I'm not sure what security
needs you would be addressing with an encrypted disk? Especially for home
users. Not the same as the CPU implementation mentioned.
You will end up with encrypted disks which will prevent the theft of
disks or the theft of data on it. So are physical locks on your door and
other physical security measures. I don't see the use for something like
this for average home users.
And of course as long as the computer is on then the encryption is
not useful.
Chris
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Diffie Hellman Primes : Speed Tradeoff Q
Date: 13 Jul 2000 15:53:51 GMT
DJohn37050 <[EMAIL PROTECTED]> wrote:
> small subgroup and lots of other considerations are discussed in the
> security annex.
Indeed. But the document recommends only that the field size
`... should be generated randomly or pseudorandomly among those field
orders with a sufficiently large subgroup' [D.4.1.2], rather than
recommending generation of Lim-Lee primes (hence, p = q R + 1 with
random large R, rather than R = 2 \prod_i r_i for large primes r_i).
The notes aren't enlightening either: they explain that choosing primes
with special forms is a bad idea, and recommend using one-way functions
for generating kosherized primes.
[I'm looking at draft 13. I didn't notice any amendments to any
relevant sections.]
I'll order the Springer-Verlag CD some time soon and read the papers
David Hopwood mentioned upthread, since this stands the most chance of
actually answering my question, which was: what are the risks of basing
the security of an algorithm on the difficulty of computing discrete
logs in a subgroup of order q in the field GF(p) where p = q R + 1 for
primes p and q, with q large enough to resist collision-finding discrete
log attacks, p large enough to resist the GNFS and R a random composite
number?
-- [mdw]
------------------------------
From: Jan Vorbrueggen <[EMAIL PROTECTED]>
Crossposted-To: comp.arch
Subject: Re: Proposal of some processor instructions for cryptographical
applications
Date: 13 Jul 2000 18:11:47 +0200
Paul Koning <[EMAIL PROTECTED]> writes:
> > I don't think the EV6 bus has byte enables.
> The Alpha architecture team had excellent arguments for leaving
> out byte load/store from the architecture.
We're talking bus, not ISA. Largely uncoupled.
> Unfortunately,
> the rest of the world was unconvinced, and this is one of
> the reasons the Alpha was far less successful than it should
> have been.
Nonsense, the presence or absence of less-than-32bits-load-store-insns was
irrelevant to Alpha's success (or not).
>
> Later on, byte operations were patched into the architecture,
> but from what you're saying it appears that support for it
> is still incomplete compared to most other architectures.
Not at all, they are quite complete.
> As a router builder, I'd take a machine with byte write support
> all the way out (i.e., byte enables on the sysbus) over one
> that doesn't, all else being equal.
But the CPU never does any bus transactions smaller than a cache line anyway.
Jan
------------------------------
From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: Using CRC's to pre-process keys
Date: 13 Jul 2000 09:34:27 -0700
In article <[EMAIL PROTECTED]>,
Scott Nelson <[EMAIL PROTECTED]> wrote:
> Suppose there was a weakness in SHA1 and it only produced
> 2^80 possible outputs when fed 128 bits.
> Admittedly, this kind of weakness
> in SHA1 is exceptionally unlikely,
> but can you prove it doesn't exist?
Actually... yeah! You can shove O(2^40) inputs through SHA1, and
see if you get a collision. If there are only 2^80 possible outputs,
you expect to see a collision -- so if you send through, say, 2^45
inputs and still see no collisions, you can conclude with pretty
high confidence that there are more than 2^80 possible outputs.
But yeah, your point is taken, and if you change 80 to 120, it becomes
much harder to detect.
------------------------------
From: "Wesley H. Horton" <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Enigma Variations
Date: Thu, 13 Jul 2000 12:17:20 -0500
John,
Am I to understand that the 5 ten contact rotors on the SIGABA do not
move during encipherment? In essance, their position was set at the
begining of the encipherment and they remained static?
Regards,
Wesley Horton
------------------------------
From: Bob Silverman <[EMAIL PROTECTED]>
Subject: Re: Diffie Hellman Primes : Speed Tradeoff Q
Date: Thu, 13 Jul 2000 17:10:13 GMT
In article <[EMAIL PROTECTED]>,
Anton Stiglic <[EMAIL PROTECTED]> wrote:
> Bob Silverman wrote:
> >
<snip>
> Hmmm, I was playing around with Open-SLL prime number generator.
> Generating a 2048 bit strong pseudo-prime (you want a strong prime p =
> 2q + 1
> in DH for different reasons,
You can't possibly mean this. Why would you want a pseudo-prime????
--
Bob Silverman
"You can lead a horse's ass to knowledge, but you can't make him think"
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Bob Silverman <[EMAIL PROTECTED]>
Subject: Re: Diffie Hellman Primes : Speed Tradeoff Q
Date: Thu, 13 Jul 2000 17:13:17 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Mark Wooding) wrote:
> Anton Stiglic <[EMAIL PROTECTED]> wrote:
>
> > As far as I know, there is no problem, as long as you work in the
> > subgroup of a large prime. You want to be careful against Discreet
> > Log attacks on the larger group (mod p), but with at least one prime
> > factor of p-1 being large enough, I think your o.k. I'd work with
> > Lim-Lee primes just to be on the safe side however...
>
> Right, thanks. I'm aware that if p = q R + 1 where R is smooth then
> discrete logs aren't so difficult.
Huh? They still take O(sqrt(q))! As long as q is large, the structure
of R doesn't matter.
--
Bob Silverman
"You can lead a horse's ass to knowledge, but you can't make him think"
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Date: 13 Jul 2000 18:01:50 GMT
Subject: Re: Diffie Hellman Primes : Speed Tradeoff Q
If you recall, DSA was changed to incorporate a canonical seeded hash method of
generation of p and q. This was because of concerns that special rare forms of
these are weak. This is known as Dan Gordon's attack and is also relevant.
Don Johnson
------------------------------
** 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
******************************
