Cryptography-Digest Digest #465, Volume #14 Mon, 28 May 01 17:13:01 EDT
Contents:
Re: A generic feistel cipher with hash and gf(257) mixers (Jim Steuert)
Logically securing a laptop ("§eeker")
Re: A generic feistel cipher with hash and gf(257) mixers (David Wagner)
question on Luby's book (David A Molnar)
Re: RSA keysize doubling techniques (Uenal Mutlu)
Re: Good crypto or just good enough? ("Sam Simpson")
Re: Logically securing a laptop ("Sam Simpson")
Fractionated Morse - Help (Charles Eastwood)
Discrete Log question (Tom St Denis)
Re: Medical data confidentiality on network comms (Larry Kilgallen)
Re: Medical data confidentiality on network comms (Larry Kilgallen)
Re: Good crypto or just good enough? (David Wagner)
Re: Euroean commision will recommend all citizens to use encryption in email next
week, because of echelon. (Crypto Neophyte)
Re: Quantum Computers with relation to factoring and BBS ("Scott Fluhrer")
Re: question on Luby's book ("Paul Pires")
Re: Medical data confidentiality on network comms ("Roger Schlafly")
----------------------------------------------------------------------------
From: Jim Steuert <[EMAIL PROTECTED]>
Subject: Re: A generic feistel cipher with hash and gf(257) mixers
Date: Mon, 28 May 2001 15:22:36 -0400
Thanks for your help, David.
Why wouldn't a Luby-Rackoff cipher qualify
as such a class of ciphers, subject, of course, to
assumptions about the hashes which are used?
The Shazam cipher paper claimed to be
"as secure as SHA-1".
David Wagner wrote:
> Jim Steuert wrote:
> > a) Use at least one more key part, and blend it in. The attack is thus
> > on =>(xor k1)=>H=>(xor k2)=>J=>(xor k3)=>K=>(xor k4)=>
>
> Assuming that H,J,K have no exploitable structure, and k1,k2,k3,k4
> each are 32 bits of independent key material, I can't immediately
> see any attacks with less than 2^64 complexity. (Guess k1,k2 and
> work forwards; guess k4,k3 and work backwards; and meet in the middle:
> this requires 2^64 work, since k1,k2 contain 64 bits of key.)
>
> > b) Re-use the parts of the key at the various stages, [...]
>
> Ahh, yes. This is known as a key schedule.
>
> >While the original specification of my cipher was flawed, is there
> >anything fundamentally wrong with the methodology or recipe, given those
> >(important) fixes, to generate a reasonable cipher?
>
> I don't know how to answer this question. I'm not sure whether
> it even has a meaningful answer as posed.
>
> I suspect you'll have to be much more precise about your methodology,
> your definition of how you choose a key schedule, how you choose an
> "invertible hash", and so on, before one can something useful about
> the methodology in the aggregate. Otherwise, the only meaningful
> answer is likely to be the trivial one: "there exist instances of
> ciphers that appear to follow the methodology but are insecure".
>
> Nor am I convinced yet that there is a "recipe" for building secure
> block ciphers, at your level of generality.
>
> In general, we do not have even a single useful block cipher that
> is provably secure at all (let alone "recipes" for entire families of
> secure ciphers), and there are strong reasons to believe that designing
> a provably secure block cipher is not an easy task.
------------------------------
From: "§eeker" <[EMAIL PROTECTED]>
Subject: Logically securing a laptop
Date: Mon, 28 May 2001 19:23:35 GMT
I recently purchased a laptop and am concerned about the confidential
information that I may have on it. I am interested in encrypting the hard
disk such that I can log on to it for access, but should I lose it or should
it get stolen, the data will be secure. The security should be sufficiently
strong against brute-force, boot-disk access, etc. Any recommendations?
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: A generic feistel cipher with hash and gf(257) mixers
Date: Mon, 28 May 2001 19:25:31 +0000 (UTC)
Jim Steuert wrote:
>Why wouldn't a Luby-Rackoff cipher qualify
>as such a class of ciphers, subject, of course, to
>assumptions about the hashes which are used?
Yes, that could get you part of the way. (But the assumptions about
the properties of the hashes tell you nothing about how to actually
instantiate those hashes in an implementation.)
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: question on Luby's book
Date: 28 May 2001 19:10:23 GMT
I just picked up Luby's _Pseudorandomness and Cryptographic Applications_.
My copy has what looks like a publishers' error. On page 32, the page
terminates in the middle of a discussion of security-preserving reductions
with the words
"It turns out that the primary quantity that determines the strength of
the reduction is the ration s'(n)/s(n). The bigger the ratio the more"
and then on p.33 where the punchline should be, my copy has "Lecture 3"
starting.
Does anyone know if there's a correct printing of the book (i.e. is it
worth it for me to contact the publisher and ask for a new copy?)
If there is, does anyone know what the punchline is above? Is it different
from the discussion in the HILL paper?
thanks,
-David Molnar
------------------------------
From: Uenal Mutlu <[EMAIL PROTECTED]>
Crossposted-To: sci.math.num-analysis
Subject: Re: RSA keysize doubling techniques
Date: Sun, 27 May 2001 18:26:07 +0200
On 28 May 2001 17:12:32 GMT, jlcooke <[EMAIL PROTECTED]> wrote:
>Yes, they arn't pretty. You'll need to use it to do additions only.
>Since for 2048bit RSA en/de-crypts you need 2048 multiplies.
>
>In other words, the speed up you'll get from the addition will not be
>enough to outweigh the loss in I/O to the device.
>
>JLC
There is a scientific paper about this:
http://www.gemplus.fr/smart/r_d/publications/crypto1.htm
If I interpreted it right, then they only need 9 multiplications.
>Uenal Mutlu wrote:
>>
>> I'm looking for methods for extending the capacity of
>> an RSA Crypto Accellerator (HW) by the factor 2.
>>
>> It has two registers of each 1120 bits and can perform
>> modular and non-modular multiplication, addition,
>> subtraction, reduction, logical XOR and shift operations.
>> This accellerator can handle RSA key sizes of up to 1024 bit.
>>
>> I would like to use a wrapper library around this
>> to extend the capacity to 2048 bits. Are there any
>> doubling algorithms to realize this?
------------------------------
From: "Sam Simpson" <[EMAIL PROTECTED]>
Subject: Re: Good crypto or just good enough?
Date: Mon, 28 May 2001 20:40:51 +0100
Thanks for the response David. I was specifically enquiring RE Douglas's
"it must be at least *slightly* more secure" statement. You show that they
must be at least equivalent, but does your proof show that 3des must be any
stronger than DES, rather than just equivalent?
Thank again,
--
Sam Simpson
http://www.scramdisk.clara.net/
"David Wagner" <[EMAIL PROTECTED]> wrote in message
news:9eu5nr$2aml$[EMAIL PROTECTED]...
> Sam Simpson wrote:
> >"Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
> >> It's not hard to see that 3DES is no less secure than DES.
> >
> >Is this a suspicion or is there a proof for this somewhere?
>
> There's a straightforward proof, which goes roughly along the
> following lines. If there is a good attack on 3DES, then you
> can use it as a black box to break DES as follows: pick 2 random
> other DES keys, and simulate 3DES using chosen-plaintext queries
> to your DES oracle along with encryption/decrypting using the
> 2 keys you picked; then if the 3DES attack can distinguish your
> simulation from random, this distinguishes DES from random.
------------------------------
From: "Sam Simpson" <[EMAIL PROTECTED]>
Subject: Re: Logically securing a laptop
Date: Mon, 28 May 2001 20:43:16 +0100
Look at: Pgpdisk, Bestcrypt, E4m, Scramdisk.
--
Sam Simpson
http://www.scramdisk.clara.net/
"§eeker" <[EMAIL PROTECTED]> wrote in message
news:XAxQ6.88844$[EMAIL PROTECTED]...
> I recently purchased a laptop and am concerned about the confidential
> information that I may have on it. I am interested in encrypting the hard
> disk such that I can log on to it for access, but should I lose it or
should
> it get stolen, the data will be secure. The security should be
sufficiently
> strong against brute-force, boot-disk access, etc. Any recommendations?
------------------------------
From: [EMAIL PROTECTED] (Charles Eastwood)
Subject: Fractionated Morse - Help
Date: 28 May 2001 12:53:26 -0700
Can anyone point me to references on breaking fractionated Morse
messages?
I think there are at least two types. In one the Morse string,
including "X" for letter breaks, is divided into groups of three
characters. A table is then used to turn each group into one letter of
the CT. In the other system a string of numbers is formed based on
the number of dots and dashes in each letter. That string of numbers
is transposed, and then used to generate a new Morse string which is
then converted to letters.
I am interested in attacks on both systems.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Discrete Log question
Date: Mon, 28 May 2001 20:18:12 GMT
I am writting a homebrew PK system (just for fun) and I was wondering
something...
I want to use the user password as the key so no private key must be
stored on the disk (this also makes the private key portable) so I am
using SHA256...
I made a prime P such that P-1/2 is a big prime and P-1/2 is not 3
(duh....).
I take the hash of the passphrase H and convert it to a 256-bit number.
I then use x=H^3 as the private DH exponent.
Is this vulnerable to the DLP attacks which make use of limited range
exponents?
Tom
------------------------------
From: [EMAIL PROTECTED] (Larry Kilgallen)
Crossposted-To: comp.security.misc
Subject: Re: Medical data confidentiality on network comms
Date: 28 May 2001 16:22:54 -0500
In article <VvtQ6.29$[EMAIL PROTECTED]>, "Roger Schlafly"
<[EMAIL PROTECTED]> writes:
> "Larry Kilgallen" <[EMAIL PROTECTED]> wrote
>> > Personally, I'd be quite happy with 56-bit ciphers and 512-bit PK keys
>> > if the various other privacy leaks were plugged. The real medical
> privacy
>> > threats have almost nothing to do with crypto.
>> But some of them are susceptible to cryptographic controls.
>> Consider the issue of delegation. My doctor can see my
>> medical records. My doctor should be able to delegate
>> the ability to see those records to a specialist for a
>> limited amount of time, but without delegating unlimited
>> rights to further delegation. Some number of emergency
>> room doctors should be able to unseal my records in the
>> absence of my doctor if they all agree and the access is
>> strongly audited (alarmed) with guaranteed notification
>> to my doctor and me. These are all issues where there
>> might be some cryptographic assistance as part of the
>> total solution.
>
> There would have to be a culture change among physicians if anything
> like that were to take effect. US physicians just don't believe
> in those sorts of limits. And patients just don't have enough
> power to ask for limits like that.
That's why it took US federal government action to get providers stirred
up. (I have no knowledge of the details of the new requirements, but at
least they are talking about it.)
I think institutional resistance to limits is actually less of a problem
than is the volume of affected code written in MUMPS. I see no clean
way for MUMPS (M, if you will) programs to be required to depend upon
the operating system for security, so you end up having the applications
programmers responsible for the security features. That is always a bad
move, even with the best of intentions, because security is not the basis
for their performance evaluations.
------------------------------
From: [EMAIL PROTECTED] (Larry Kilgallen)
Crossposted-To: comp.security.misc
Subject: Re: Medical data confidentiality on network comms
Date: 28 May 2001 16:25:05 -0500
In article <[EMAIL PROTECTED]>, Anne & Lynn Wheeler <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] (Larry Kilgallen) writes:
>
>> But some of them are susceptible to cryptographic controls.
>> Consider the issue of delegation. My doctor can see my
>> medical records. My doctor should be able to delegate
>> the ability to see those records to a specialist for a
>> limited amount of time, but without delegating unlimited
>> rights to further delegation. Some number of emergency
>> room doctors should be able to unseal my records in the
>> absence of my doctor if they all agree and the access is
>> strongly audited (alarmed) with guaranteed notification
>> to my doctor and me. These are all issues where there
>> might be some cryptographic assistance as part of the
>> total solution.
>
> cryptographic controls tend to be all or nothing ... you either see it
> or you don't see it.
>
> fine-grain access control systems with audit procedures can have
> real-time rules and audit trail as to which entities can see what,
> when. however, for the most part, cryptography is almost orthogonal to
> fine-grain access ... except possibly in the area of authentication
Yes, that is exactly the crucial role for cryptography - authentication.
N-out-of-M signature schemes, etc.
> bulk-encrypting all of the data and only providing the key(s) to the
> access control system could be a means to address various kinds of
> system exploits (like off-site disaster/recovery copies).
Yes, but that part is "easy".
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: Good crypto or just good enough?
Date: Mon, 28 May 2001 20:36:10 +0000 (UTC)
Sam Simpson wrote:
>Thanks for the response David. I was specifically enquiring RE Douglas's
>"it must be at least *slightly* more secure" statement. You show that they
>must be at least equivalent, but does your proof show that 3des must be any
>stronger than DES, rather than just equivalent?
No, it doesn't. It seems to be very difficult to show that 3des is
even a little bit more secure than des. I don't know of any provable
justification for the "at least *slightly* more secure" statement (but
I'd be interested to hear if there is one!).
------------------------------
From: Crypto Neophyte <[EMAIL PROTECTED]>
Subject: Re: Euroean commision will recommend all citizens to use encryption in email
next week, because of echelon.
Date: Mon, 28 May 2001 20:41:31 GMT
On Tue, 22 May 2001 18:38:51 +0000, Ichinin wrote
(in message <[EMAIL PROTECTED]>):
Snip
> I understand the corporate worries, but as a private citisen, I don't see
> the threat...
It depends on whether or not you want to get involved in politics.
George Washington in a letter to the Marquis de Lafayette, discussing plans
for the US Constitution said," although by passing through the post offices
they should become known to all the world".
As more and more people get involved in issue groups( eg, EFF,NRA, NMA)
rather than Political parties it is becoming more important to the Democrats
and Republicans to keep these groups in check. What if you were working with
the local chapter of the Sierra Club to decide if you should support one
candidate because of his support of protection of wetlands. Under the
proposed McCain-Fiengold bill you might end up in jail. (S27, passed by the
Senate in April)
The law provides for a blackout of issue advertisement for 60 Days prior to
an election if the content refers to a Federal Candidate. So if your
orginization supported Gore and you had advertisements talking about how
important the wetlands were you could do hard time in Federal prison. The
advertisements might be as simple as putting signs up in your front yard
supporting Gore and "protect our wetlands".
Another possibility is if you were involved in politics and a member of say
the local cross dressing organization. If you were accidentaly outed by
someone who had read your emails it would greatly damage your orginazation is
some town. It is a nice way of using fear to keep people uninvolved in
politics.
So if you just sit at home and watch the "weakest link" you have nothing to
fear. But if you want to be involved in your community at even a small level
the Government wants to know what you are doing.
Sure SPAM is a pain in the ass. They why I left AOL. But in the long run it
is a minor problem. Most of the spam I get right now comes from other
countries so US law doesn't apply anyway.
HKRIS
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: Quantum Computers with relation to factoring and BBS
Date: Mon, 28 May 2001 13:30:52 -0700
Bill Unruh <[EMAIL PROTECTED]> wrote in message
news:9eu1ke$njh$[EMAIL PROTECTED]...
> In <9etv2h$4pn$[EMAIL PROTECTED]> "Scott Fluhrer"
<[EMAIL PROTECTED]> writes:
> ]>
> ]> 1. Do we know factoring is NP for certain?
> ]Yes, but then again, so is the problem "is this integer even?". I
suspect
> ]what you meant was "Do we know factoring is NP-complete?", and the answer
is
> ]no, we don't. Some definitions [warning: these definitions are intended
to
> ]be easy to understand, and so they're a bit sloppy with the exact
nicities
> ]of the actual definitions]:
>
> But asking "is a problem NP" is usually a shorthand for
> "Is the problem NP but not P".
However, that is improper terminology. I both corrected the OP, answered
the question he (probably) meant, and gave him as some background
information as a bonus. Would you have prefered I kept him ignorant?
--
poncho
------------------------------
From: "Paul Pires" <[EMAIL PROTECTED]>
Subject: Re: question on Luby's book
Date: Mon, 28 May 2001 13:59:50 -0700
You're missing two whole pages
My copy has the ""The the bigger this ratio the more...." on page 32.
The are two more pages after that before page 35 which is lecture 3.
ISBN 0-691-02546-0
I can't find what edition or printing mine is. Strange.
It is a soft bound (paperback) book though.
David A Molnar <[EMAIL PROTECTED]> wrote in message
news:9eu7qv$nf2$[EMAIL PROTECTED]...
>
> I just picked up Luby's _Pseudorandomness and Cryptographic Applications_.
> My copy has what looks like a publishers' error. On page 32, the page
> terminates in the middle of a discussion of security-preserving reductions
> with the words
>
> "It turns out that the primary quantity that determines the strength of
> the reduction is the ration s'(n)/s(n). The bigger the ratio the more"
>
> and then on p.33 where the punchline should be, my copy has "Lecture 3"
> starting.
>
> Does anyone know if there's a correct printing of the book (i.e. is it
> worth it for me to contact the publisher and ask for a new copy?)
You should get a correct copy. You paid for it. (You didn't grab it and
dash did you?)
Paul
>
> If there is, does anyone know what the punchline is above? Is it different
> from the discussion in the HILL paper?
>
> thanks,
> -David Molnar
------------------------------
From: "Roger Schlafly" <[EMAIL PROTECTED]>
Crossposted-To: comp.security.misc
Subject: Re: Medical data confidentiality on network comms
Date: Mon, 28 May 2001 20:00:53 GMT
"Tom McCune" <[EMAIL PROTECTED]> wrote
> >Whether you accept RSA's reasoning or not, 2048 seems pretty conservative
> >(about 2^40 times harder than 1024), and for most purposes isn't too slow
on
> >modern PCs.
> Why I find this surprising is the issue of long term security. I'm in the
> children's unit, and who knows how this information could adversely affect
> people 10, 20, or 30 years from now. I know that 1024 bit is secure at
> this time, but betting on it over a period of decades seems foolish, and
> esp. so when going to 2048 bits (which is still less secure than the
> symmetric encryption being used) is basically at no cost to anyone.
Perhaps
> this number was determined in view of the S/MIME then in effect, rather
than
> on mathematical reality.
You could use N bits for some large value of N, and those keys will
still be accessible by human beings. And usually low-level employees.
The general public won't have access to the encrypted data anyway.
So what is the scenario in which 2048-bit RSA is better than 1024
bit RSA (or DH)? That maybe 30 years from now an employee gains
access to the encrypted files and a lot of supercomputer time, but
not to the keys? And then breaks the RSA key for the purpose of
exposing someone as having had some childhood disease? It seems
very farfetched to me.
Meanwhile, the next time the target checks into a hospital, he will
sign a blanket release that gives hundreds of clerks access to all
his medical files.
------------------------------
** 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
******************************
