Cryptography-Digest Digest #217, Volume #12 Thu, 13 Jul 00 03:13:00 EDT
Contents:
Re: New Idea - Cipher on a Disk (Mack)
Re: DES Analytic Crack (Jim Gillogly)
General Question on cryptography ("DW")
Re: New Idea - Cipher on a Disk ("Trevor L. Jackson, III")
Re: Elliptic Curves encryption (David A Molnar)
Re: Elliptic Curves encryption (David A Molnar)
Re: Limits of brute force. (Mack)
Re: General Question on cryptography (S. T. L.)
Re: Computing with Encrypted Functions (David A Molnar)
Re: New Idea - Cipher on a Disk ("Joseph Ashwood")
Re: Bit Shuffling (Jayant Shukla)
Re: cray and time needed to attack (Jerry Coffin)
Re: New Idea - Cipher on a Disk (Greg)
Re: New Idea - Cipher on a Disk (Greg)
Re: Computing with Encrypted Functions (David A. Wagner)
Re: Using CRC's to pre-process keys (Scott Nelson)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Mack)
Date: 13 Jul 2000 04:40:02 GMT
Subject: Re: New Idea - Cipher on a Disk
>> >Key management is the key ;-)
>> >How do you propose to manage the keys used by the drive's cipher(s)?
>
>> That is a tricky issue. Do you want one password/drive or multiple?
>> Do you want to divide the disk into virtual drives and then a
>> password for each (the easy way out).
>
>Like other onboard components, a cipher knows only a hard drive,
>not the data written on the drive to make virtual drives.
If the cipher is embedded into the on-disk controller
the controller could manage up to 7 units.
(ie. virtual drives) for SCSI.
Like an inverse RAID controller.
With the IDE drive only one device is normally available.
>> The SCSI interface seems a better way to go since IDE does
>> not support multiple devices per controller.
>
>Like on board buffers, faster rotation speeds, smaller sizes
>and faster data transfer rates, on board ciphers would find
>their way on both and the IDE market would be better at first
>where low end home PCs can use them and people can have some
>additional sense of security for say $30 more.
>
>
>--
>Tyranny is kept at bay by guns and will. Our government
>knows we have the guns, but they don't know if we have
>the will. Nor do we.
>The only lawful gun law on the books- the second amendment.
>
Mack
Remove njunk123 from name to reply by e-mail
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: DES Analytic Crack
Date: Thu, 13 Jul 2000 04:43:41 +0000
"Douglas A. Gwyn" wrote:
>
> Mok-Kong Shen wrote:
> > It seems that it could be advantageous to first try the diverse
> > ideas out on a miniature version of DES to gain experiences of
> > which methods are the best.
>
> No, absolutely not -- I am tired of solutions for "toy problems"
> that do not scale. The whole point of the exercise was to develop
> a technique that would be effective against a large class of real-
> world cryptosystems. If one doesn't start out with that goal,
When I tried this approach in the early 80's my thought was that if
there were a back door in DES it might be signalled by a catastrophic
collapse in the complexity of the Boolean equations at some point
during the simplification process. Unfortunately I didn't have the
horsepower available at the time and gave up less than half-way
through the 16 rounds, without having found a dramatic simplification.
I haven't gotten back to it since.
--
Jim Gillogly
Highday, 20 Afterlithe S.R. 2000, 04:40
12.19.7.6.14, 8 Ix 17 Tzec, Eighth Lord of Night
------------------------------
From: "DW" <[EMAIL PROTECTED]>
Subject: General Question on cryptography
Date: Thu, 13 Jul 2000 04:53:09 GMT
This is probably a naive question, and is probably addressed in a source
that I'm not aware of (perhaps someone could direct me to a source), but
one of the things that's always made me curious about cryptography is
why can't someone develop a combination of algorithms that no one
would ever think of in attacking encrypted data?
Just to give you an example, one might take a plain text, convert it to a
binary stream, convert that to 32 bit unsigned integers, take the FFT,
reverse the
real and imaginary parts, re-order the resulting bitstream by reversing the
order of every block of n+2 bits, where n is the day of the month modulo
the day of the week, and finally perform RSA on the result.
How would one attack data encrypted by such an algorithm? It seems like
you need to have an idea of the algorithm used and maybe
even the order, and I don't see how one would guess this? Can you attack
it mathematically to decrypt it without discovering each algorithmic
operation after many many several messages have been sent?
--
DW
------------------------------
Date: Thu, 13 Jul 2000 01:10:49 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: New Idea - Cipher on a Disk
Greg wrote:
> > Greg wrote:
> >
> > > I was looking over a thread on the question of adding hardware
> > > support to a CPU. The problem there is that the CPU must be
> > > flexible enough to support various types of ciphers if you go
> > > that route.
> > >
> > > What if a disk drive came with a cipher on the disk, and supported
> > > a new ATA instruction set that took advantage of these ciphers?
> > >
> > > The cipher can be very specific for that disk drive. It can be
> > > a FEATURE of the disk drive, much like transfer speeds and buffer
> > > sizes are marketing features. The cipher can be strong. The disk
> > > drive manufacturers would compete for cipher strength and speed,
> > > much like they do now for transfer speed. All of the software
> > > is eliminated and this feature is completely transparent. There is
> > > no CPU overhead. Multiple disks can work independently of each
> > > other.
> > >
> > > Sounds like a great idea for Fujitsu and IBM to incorporate into
> > > their drives! But, alas, I proposed it here in the public domain...
> >
> > Key management is the key ;-)
> > How do you propose to manage the keys used by the drive's cipher(s)?
>
> 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?
It's a start. I was partly concerned with the persistence of the encryption
key. Is it entered by the user at every power up? every reboot?
But the harder problem is getting the key from the user to the disk. There's
no existing mechanism for this. So you'd need to extend each interface to
include key management commands. Bottom line is that I don't think you can
implement an encrypting drive as a replacement for an existing non-encrypting
drive. At least you would have to change the disk controller, and with IDE
drives that means replacing the motherboard.
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: Elliptic Curves encryption
Date: 13 Jul 2000 04:34:19 GMT
Greg <[EMAIL PROTECTED]> wrote:
> I got a password and now I regret it. Why won't they just
> make it freely available? I now get e-mail all the time
> on ongoing conversations between other members of the group
I think that there is an IEEE bylaw which requires working groups
to keep draft documents "safe." This may be because the final
standard is a product of the IEEE which we are supposed to pay $$$ for.
By making the draft documents available with a password, then giving
out the password to most anyone, the working group can satisfy
both the bylaw and the need to disseminate information.
This is founded on a hazy recollection, however, and should probably be
checked.
> that I don't care for. Perhaps it is easy to remove? But
> it is really silly to begin with...
You can unsubscribe from the mailing list. Instructions should
be on the web page someplace. I haven't been getting much p1363-discuss
mail lately, though -- maybe I've missed something?
-David
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: Elliptic Curves encryption
Date: 13 Jul 2000 04:35:18 GMT
Nicol So <[EMAIL PROTECTED]> wrote:
> Does applying for access automatically sign you up for their mailing
> list?
I think the thing is that one way of obtaining the password is to
sign up for the mailing list. Then they send it to you in
the confirmation message.
It was a cute password, too. at least last time I looked.
-David
------------------------------
From: [EMAIL PROTECTED] (Mack)
Date: 13 Jul 2000 05:07:14 GMT
Subject: Re: Limits of brute force.
>All of this assumes that you have a classical computer that follows the
>Church-Turing model of computation. If we have a quantum computer which
>we could run Grover's algorithm on, the limits change significantly.
>Since Grover's algorithm allows you to perform an unordered search in
>O(sqrt(N)) time, you'd have to double the number of bits in your
>estimate, provided quantum computers which have an arbitrary number of
>qubits are practical.
>
>--
>Rafael R. Sevilla <[EMAIL PROTECTED]> +63 (2) 4342217
>ICSM-F Development Team +63 (917) 4458925
>University of the Philippines Diliman
>
>
For the 256 bit limit I was assuming that one atom of hydrogen could
be used to preform one operation in the length of time it takes one
quantum to cross said atom and that enough of these atoms were
accumulated to equal the weight of the moon. Further this could
somehow magically notify us if it produced the correct answer.
And additionally we could reset the state instantaneously and
try a new answer.
This is kind of a weird assumption since it is assuming that
one hydrogen atom can accumulate and process information
on a complex level. Specifically one trial encryption.
As I haven't really gotten into quantum cryptography, I can't
really make a judgement if there is a way to improve on this.
But since quantum computing is still not practical, nor is
it likely to produce the massive parrallelism I have described,
I think 256 bits is reasonably safe against brute force.
That said, brute force is seldom the most effecient method.
Mack
Remove njunk123 from name to reply by e-mail
------------------------------
From: [EMAIL PROTECTED] (S. T. L.)
Subject: Re: General Question on cryptography
Date: 13 Jul 2000 05:12:46 GMT
<<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.
-*---*-------
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: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: Computing with Encrypted Functions
Date: 13 Jul 2000 05:16:12 GMT
Austin Godber <[EMAIL PROTECTED]> wrote:
> Hello,
> I have recently come across an article on computing with encrypted
> functions by T. Sander and C. Tscudin called "Protecting Mobile Agents
> Against Malicious Hosts".
> I have tried to find some additional references along these lines but
> have only found very few. (One from C. Cachin ... IBM Zurich and an
> older one from A.C. Yao). I was wondering if anyone here is familiar
> with this topic and if there is any current research I can look into.
I'm not exactly familiar with it...it just pops up here and there...
Non-Interactive CryptoComputing for NC^1
Sander, Young, and Yung
http://www.computer.org/proceedings/focs/0409/04090554abs.htm
Ke Yang and a cast of thousands at CMU on "code obfuscators"
http://www.cs.cmu.edu/~yangke/research.html
(Said cast includes people like Salil Vadhan, Oded Goldreich, Russell
Impagliazzo, and so on - check the slide presentation for details)
(By the way, what is the deal with the slide stating "code obfuscators
imply correlation intractable hash functions with output longer than seed
length" just before the slide on "correlation intractable hash functions
with output longer than seed length impossible" just before "existence of
obfuscators is an open question" ?)
Security in Mobile Agent Systems (bibliography)
not QUITE what you want, more a superset
http://www.cs.vu.nl/~niek/mas/mobile_security.html
Environmental Key Generation towards Clueless Agents
Riordan and Schneier
http://www.counterpane.com/clueless-agents.html
A special case would be Matt Skala's construction for blind substring
matching :
A Limited Diffusion Algorithm for Blind Substring Search
Matt Skala
http://www.islandnet.com/~mskala/limdiff.html
See also "Cloakware Corporation," which advertised for jobs in this
newsgroup recently. They claim to have a working, production code
obfuscation technology.
The field of private information retreival is probably tangentially
related as well, if you consider a query as a "program" which "runs"
on the database and returns encrypted data to the querying party.
Then the goal is to prevent the database from discovering for what
the "progam" is looking.
-David
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: New Idea - Cipher on a Disk
Date: Wed, 12 Jul 2000 22:30:11 -0700
> 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.
> At least you would have to change the disk controller, and
with IDE
> drives that means replacing the motherboard.
That is true, I think most disk controllers would choke if
you tried to write to that block.
Joe
------------------------------
From: [EMAIL PROTECTED] (Jayant Shukla)
Subject: Re: Bit Shuffling
Date: 13 Jul 2000 05:37:37 GMT
"Adam Durana" <[EMAIL PROTECTED]> writes:
>This is a total rip off of something I posted early in 1999. I called it
>"slotting" and the only difference between what you present here and what I
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
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.
best regards,
Jayant
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: cray and time needed to attack
Date: Wed, 12 Jul 2000 23:52:52 -0600
In article <8kjbqp$ips$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
says...
[ ... ]
> If I poured in $100M, how quick could I get the key
Not in any reasonable length of time.
> and what would that key "generally" give me in return?
"Generally"? The huge expenditure would _probably_ get a message
about the simply incredible girl some teenage boy met at the party
after he snuck out Friday night (of course, by the time you finish
decrypting it, he's not a teenager and doesn't live at home anymore).
Oops -- we meant to get the message from his Dad, who's the president
of the bank. Unfortunately, after spending the time and effort to
decrypt his message, instead of the combination to the vault, we find
out about how his temporary secretary at the time looked in a
miniskirt (and how his wife would claw his eyes out if she found
out...) <G>
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
From: Greg <[EMAIL PROTECTED]>
Subject: Re: New Idea - Cipher on a Disk
Date: Thu, 13 Jul 2000 05:52:31 GMT
> If the cipher is embedded into the on-disk controller
> the controller could manage up to 7 units.
> (ie. virtual drives) for SCSI.
> Like an inverse RAID controller.
You want to keep the cipher with the data.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Greg <[EMAIL PROTECTED]>
Subject: Re: New Idea - Cipher on a Disk
Date: Thu, 13 Jul 2000 06:00:45 GMT
> > 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?
>
> It's a start. I was partly concerned with the persistence of
> the encryption key. Is it entered by the user at every power
> up? every reboot?
Depends on the BIOS or the disk commands for passing the password
from the BIOS to the disk. But what ever the design, it would be
pretty much laid in cement for years.
> But the harder problem is getting the key from the user to the
> disk. There's no existing mechanism for this. So you'd need to
> extend each interface to include key management commands.
No. Just extend the ATA (for example) to include new commands
that allow passing a password. The key persists with the HD power
and reset.
> 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.
> At least you would have to change the disk controller, and with IDE
> drives that means replacing the motherboard.
Again, using my example above, the controller can be ATA5 and still
use an ATA6 drive in ATA5 mode. When the user wants to upgrade the
MB, he can select an ATA6 compliant MB to use the cipher features
of the HD. In this way, the feature does not interfere with where
the HD can be used (until its cipher is used, then it can only be
read by ATA6 controller supported machine).
It is how you invest into some hardware today hoping to take advantage
of its full features tomorrow when you will have the money to upgrade
to a new MB with a more powerful and faster CPU, etc...
--
Tyranny is kept at bay by guns and will. Our government
knows we have the guns, but they don't know if we have
the will. Nor do we.
The only lawful gun law on the books- the second amendment.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: Computing with Encrypted Functions
Date: 12 Jul 2000 23:32:21 -0700
Here's one that I happen to be fond of:
``Practical Techniques for Searches on Encrypted Data'',
Dawn Song, David Wagner, and Adrian Perrig.
Proc. of IEEE Symposium on Security and Privacy, May 2000.
http://paris.cs.berkeley.edu/~dawnsong/papers/se.ps
------------------------------
From: [EMAIL PROTECTED] (Scott Nelson)
Subject: Re: Using CRC's to pre-process keys
Reply-To: [EMAIL PROTECTED]
Date: Thu, 13 Jul 2000 06:59:36 GMT
On Tue, 11 Jul 2000, David Hopwood <[EMAIL PROTECTED]> wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>
>"David A. Wagner" wrote:
>> In article <[EMAIL PROTECTED]>,
>> Scott Nelson <[EMAIL PROTECTED]> wrote:
>> > If we assume that the hash is completely unbiased
>> > within the 128 bit space, hashing all possible 128 bit
>> > keys would result in approximately 1/e values being
>> > missed, and 1/e single hits, with the rest being
>> > hit multiple times. Effectively reducing the key
>> > space by less than 3 bits, which I agree is pretty
>> > irrelevant in most cases. It's not 0 though, so this
>> > is an advantage that CRC has over SHA1.
>>
>> Yup, looks irrelevant to me. Brute-forcing a 125-bit keyspace is utterly
>> infeasible, so this 'advantage' of CRC over SHA1 appears negligible to me.
>
>Not to mention that, unless SHA-1 has some serious weaknesses, there's no
>way to characterise the set of possible keys in a way that would
>allow you to reduce the expected work factor to less than 2^127. I.e.
>you don't know where the collisions are without hashing as many values
>as would be needed for simple brute-force.
>
It depends on how much faster or slower the hash is than
a key test. Hashing is usually a quicker process than key
testing, so an advantage can be gained by testing the
hash of a key. Besides, if you're silly enough to consider
brute forcing 128 bit keys, you're probably silly enough to
consider precomputing the hashes.
This weakness is more theoretical than actual,
and might be better stated as "the relation between
a secure hash of a 128 bit key and the key is unknown,
whereas the relation between CRC (or other simpler function)
is both known and provable to be 1 to 1."
Suppose there was a weakness in SHA1 and it only produced
2^80 possible outputs when fed 128 bits.
This would change from impractical key space reduction,
to major problem. Admittedly, this kind of weakness
in SHA1 is exceptionally unlikely,
but can you prove it doesn't exist?
I know it seems silly to ask for this level of proof,
but that's not going to stop some people.
(There are examples of people like that in this very thread.)
Scott Nelson <[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
******************************
