Cryptography-Digest Digest #476, Volume #14 Wed, 30 May 01 11:13:01 EDT
Contents:
Re: Crypto NEWBIE, wants to create the 100% SAFE FRACTAL encoding... (Sergei Lewis)
Re: Euroean commision will recommend all citizens to use encryption in email next
week, because of echelon. ("Harris Georgiou")
Defeating the Correlation Attack (John Savard)
Re: "computationally impossible" and cryptographic hashs (Roger Fleming)
Re: Best, Strongest Algorithm (SCOTT19U.ZIP_GUY)
Re: Crypto neophyte - programming question (jlcooke)
Re: Good place to start? (jlcooke)
Re: Medical data confidentiality on network comms (Roger Fleming)
Re: Medical data confidentiality on network comms (Lassi
=?iso-8859-1?Q?Hippel=E4inen?=)
Re: unpredicable random number generator ? (Mok-Kong Shen)
Re: Cool Cryptography Website! (Mok-Kong Shen)
Is this a weakness in RSA key generation? (Mark Borgerding)
Re: Medical data confidentiality on network comms ("Roger Schlafly")
----------------------------------------------------------------------------
From: Sergei Lewis <[EMAIL PROTECTED]>
Subject: Re: Crypto NEWBIE, wants to create the 100% SAFE FRACTAL encoding...
Date: Wed, 30 May 2001 11:27:51 +0100
BenZen wrote:
> Sergei Lewis wrote in message ...
> >..if you say all that, then why don't you just use the bits of Pi?
> Because; I always had these impressions:
>
> 2- I always thought calculating PI to the N'th digit involves being able to
> process N'th and more width; Requiring relatively powerful computers,
> contrary to compute a simple Fractal equation: z[n+1]=z[n]*z[n]+c, z[0]=0.
> That was possibly true before the recent algorithm.
Hmp. The problem, though, you see, is that effectively what you are
doing, whether you are using a fractal or the digits of Pi, is you are
making a PRNG that produces a stream of data, using either a key (in
which case you combine your output with the plaintext to encrypt), or a
combination of the key and your plaintext input as its seed. The PRNG
has to have certain properties - if it produces a repeating sequence of
bits, this cannot be much shorter than messages you encrypt with it,
because otherwise you could do some fairly trivial cryptanalysis on it
(see FAQ); it has to produce different sequences for different keys,
that do not overlap; and the sequences have to be reproducible (so you
can decrypt the data at the other end; in symmetric cryptography, the
(unique) key that reproduces the sequence is the original encryption
key, whereas with public key crypto there is a unique key that
reproduces the sequence and is not the same as the encryption key, *and*
is not feasibly deducible from it.
Now, the using-keyed-sections-of-Pi-as-a-pad algorithm obeys this, and
is secure (provided a different key is used for *every* message sent,
you are effectively selecting from 2^keylength one-time pads). The same
is true of the fractal algorithm, provided the various implementation
problems (guaranteeing output is not periodic or infinite) are solved.
The same is also true to various extents of the more conventional
ciphers - IDEA, Rijndael, TEA, the various ones Tom St. Denis suggests
every so often.
They all share the same disadvantage: namely, you have to find some
secure way of sharing keys.
However, they have a major advantage over Pi and fractals: the
combinations of shifts, adds and XORs they tend to use are very easy to
implement for quick and/or hardware calculation.
Now, if there was some way to get a public crypto algorithm out of
fractals, that might be really interesting ^-^ RSA is slow. Perhaps one
could bounce around the inside of the boundary of the fractal set, the
way one bounces along the curve in elliptic curve crypto, with a
would-be cryptanalyst having to solve the discrete log problem?
--
Sergei Lewis - http://members.tripod.co.uk/~Folken
"I'm not falling - this is how I fly.."
------------------------------
From: "Harris Georgiou" <[EMAIL PROTECTED]>
Subject: Re: Euroean commision will recommend all citizens to use encryption in email
next week, because of echelon.
Date: Wed, 30 May 2001 14:32:20 +0300
� Lassi Hippel�inen <[EMAIL PROTECTED]> ������ ��� ������
���������: [EMAIL PROTECTED]
> Harris Georgiou wrote:
> ...
> > Since encryption can be used on public scale only for e-mail and
computer
> > comms (using any of the freeware packages), then PKI is not really a
> > problem, since all these packages work quite well over the Internet for
many
> > years now (take PGP for example).
>
> But PGP *has* a PKI of its own...
Exactly. But moving from normal mail to encrypted mail by ALL users
(gradually) over the Internet - that's a real nightmare for the intelligence
agencies thoughout the world.
> That's the problem. When 3G phones roll out in a serious manner, there
> will be gazillions of mobile computers, connecting from volatile
> addresses. PKI will be needed to authenticate the users, no matter if it
> is done in IP or application layer.
Maybe the authentication issue will be solved (partially) by using some kind
of smartcards instead of the dummy SIM cards no in use by all cellphones. Of
course none talks about keys and passwords tampering or eavesdropping.
> IESG just recently rejected the proposal to use IPSec AH, in order to
> authenticate Mobile IPv6 Binding Updates. One argument was that there is
> no PKI in sight that could handle the load.
In other words: user confidentiality is not profitable so why bother
offering it?
Nice.....really nice......
--
Harris
- 'Malo e lelei ki he pongipongi!'
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Defeating the Correlation Attack
Date: Wed, 30 May 2001 12:18:20 GMT
I had thought that the shift register cipher Intel used as part of the
High-Bandwidth Content Protection standard it developed was quite an
impressive stream cipher based on linear-feedback shift registers
(LFSRs). Of course, like anything, it could be made more elaborate,
but since it embodied a principle which resembled the
MacLaren-Marsaglia PRNG, it seemed to me to be better than the other
designs I'd seen mentioned.
However, a post appeared noting that it was still, at least to a
limited extent, vulnerable to a correlation attack. This inspired me
to look at various possibilities for using that design as a starting
point, but modifying it in ways that would reduce the effectiveness of
that attack down to vanishingly low levels.
The thoughts I had in this area are now recorded in the second part of
the page
http://home.ecn.ab.ca/~jsavard/crypto/co4y12.htm
illustrating one way of defeating this attack. However, there is one
defect of the type of design I regarded as the most effective; since
it produces an output which is a function of bits drawn from the
previous output sequence over a long period, it requires the circuit
to run for a considerable number of cycles before the delay shift
registers "fill up" with bits produced by the generator LFSRs.
One way to solve this is to include extra circuitry to fill those
shift registers in a direct instead of randomized fashion during a
special start-up state.
John Savard
http://home.ecn.ab.ca/~jsavard/frhome.htm
------------------------------
From: [EMAIL PROTECTED] (Roger Fleming)
Subject: Re: "computationally impossible" and cryptographic hashs
Date: Wed, 30 May 2001 11:10:24 GMT
"Dj Le Dave" <[EMAIL PROTECTED]> wrote:
>Related to this, I always wondered why UNIX (and other such systems) bother
>to hash at all. Could they not just "encrypt" the entire password, so to
>speak? Break it up into 56-bit blocks (or whatever) and perform the hash
>independantly on each block, then concat. all the output together [...]
>Any Comments?
First, this would make it possible for the attacker to attack each block of
password separately, so that longer passwords give only a linear increase in
strength. Secondly, most effective password cracker work forwards from a
dictionary of probable passwords; this approach would make no difference to
the difficulty of such attacks.
>"Daniel Graf" <[EMAIL PROTECTED]> wrote in message
>news:[EMAIL PROTECTED]...
>> I have a basic question about cryptographic hashes. A friend
>> and I were talking about how the hash algorithm used some UNIX
>> machines uses only 64 (or so) bits of the password.
56 bits, actually, if you're talking about crypt().
>> Now, I don't know much of anything about cryptography, but I
>> have used hash algorithms for use with hash-tables. Are
>> cryptographic hashes mostly dissimilar, or am I wrong in guessing that
>> more than one input at a Unix login prompt may match the string found
>> in the passwd file? (particularly for passwords greater than 8
>> characters).
For the old crypt() function, characters after the first 8 are just discarded,
which makes it trivial to find multiple passwords with the same output. For
the first 8 characters plus12 bits of salt, though, it is _possible_ to find
two passwords with the same output (by the pigeonhole principle, they must
exist, since 56+12 bits of input are producing 64 bits of output).
[...]
>> Does "computationally impossible" mean literally that such a
>> thing cannot happen?
No, it means the computing resources to find such a solution are too great.
For crypt(), by the way, that isn't the case, and such duplicates have been
found. Hence many systems are replacing crypt() by stronger hashes.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Best, Strongest Algorithm
Date: 30 May 2001 11:48:01 GMT
[EMAIL PROTECTED] (Benjamin Goldberg) wrote in
<[EMAIL PROTECTED]>:
>Tim Tyler wrote:
>>
>> "Most types of padding used in association with modern cyphers result
>> in a non-bijective map between the space of possible plaintexts and
>> the space of possible cyphertexts."
>
>And how is a bijective map an advantage in this case? Doesn't it imply
>that two identical plaintexts enciphered under the same key will result
>in the exact same ciphertexts?
Unless one is talking about the adding of random info. the ecnryption
program would result in the same exact ciphertext. If the exact same
plaintext when using the same key. This should happen in any crypto
program then doesn't use random data.
>
>It seems to me that the bicom chaining mode has to be one which somehow
>works without padding (in any ordinary sense of the word padding) for it
>to have the properties claimed.
BICON actaully uses a form of "normal" CBC type of chaining.
But one could easily make it so that if one does not like the
same plaintext to map to same ciphertext. for same key. Write
a front end on that pads the front of file with so a random
20 characters. then when you encrypt the same file twice you
get a different output if the random front end changed. Also
when you decrypt you drop the first 20 random cahracters.
Is this what you mean or are looking for.
Amd if you think about it. If your stuck a one character file
in. The code only uses full RIJNDAEL blocks for encryption so
it has to pad at least some of the time. THe difference is
the AES people choose to use non bijective padding. I had complained
about this in previous standards and in the AES forum. But it
has fallen on deaf ears. They don't want bijective padding.
Which means they want to be able to throw out many keys if you
use say CBC encyrption they don't wish to make it hard on the
NSA people whose job it will be to read such messages.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE "OLD VERSIOM"
http://www.jim.com/jamesd/Kong/scott19u.zip
My website http://members.nbci.com/ecil/index.htm
My crypto code http://radiusnet.net/crypto/archive/scott/
MY Compression Page http://members.nbci.com/ecil/compress.htm
**NOTE FOR EMAIL drop the roman "five" ***
Disclaimer:I am in no way responsible for any of the statements
made in the above text. For all I know I might be drugged or
something..
No I'm not paranoid. You all think I'm paranoid, don't you!
------------------------------
From: jlcooke <[EMAIL PROTECTED]>
Subject: Re: Crypto neophyte - programming question
Date: 30 May 2001 13:41:11 GMT
Look for an algorithm called base64. This will convert 3 bytes into 4
ASCII chars in a..z, A..Z, 0..9, + and /
JLC
edt wrote:
>
> I'm just getting into crypto (as of yesterday), and I'm coding a very
> simple script to XOR a textfile with a passphrase.
>
> After doing all the XORs, I get ASCII values between 1 and 127. I want
> to convert these to display-friendly ASCII (i.e. values between 32 and
> 126).
>
> How can I munge the values to get them printable, but in a way that can
> be decrypted later?
>
> This may be a dumb question for this group, but some of you must have
> done this before. Thanks...
>
> -eric
------------------------------
From: jlcooke <[EMAIL PROTECTED]>
Subject: Re: Good place to start?
Date: 30 May 2001 13:45:23 GMT
http://www.rsa.com/rsalabs/faq/
Paul Rubin wrote:
>
> "The archgimP" <althalus@excitedotcom> writes:
> > Are there any 'Faqs' for this NG which could help me get started?
>
> Yes, the sci.crypt FAQ (in 10 parts) is excellent. It gets posted here
> every few weeks. You might find it on sci.answers.
>
> > Are there any good 'suggested reading' lists for catching up with some of
> > the more recent developments...
>
> You could start with: Applied Cryptography, by Bruce Schneier (the standard
> reference for this newsgroup); and Security Engineering, by Ross Anderson
> (less specifically about cryptography, but more stuff about the UK legal
> situation and so forth).
------------------------------
Crossposted-To: comp.security.misc
From: [EMAIL PROTECTED] (Roger Fleming)
Subject: Re: Medical data confidentiality on network comms
Date: Wed, 30 May 2001 12:59:20 GMT
I'm not saying 1024 bits is definitely good enough, just that the ruling is
obviously based on common industry standards, and is not unreasonable. (Only a
few years ago they were recommending 512 bit keys for banking. Most e-commerce
is still done with 512 bit keys.)
Tom McCune <[EMAIL PROTECTED]> wrote:
[...]
>Not really - this HCFA ruling applies to patient data transferred over the
>internet. Once its on the internet, it may never disappear, and can
>possibly wind up anywhere, including such broad government tracking as
>Carnivore or Echelon
Never disappear? I presume you are talking about emailing it, not posting it
on a newsgroup. Email will disappear from the net in 5 - 10s unless some
cracker intercepts and archives it for 30 years in the hope of one day
decrypting it to blackmailing someone. Not completely impossible, but pretty
unlikely - especially if it is one of millions of encrypted emails, and has no
plaintext identifying it as especially interesting.
I think you are falling into the trap of focussing too narrowly on one part of
the problem and missing the rest, as Roger was suggesting. There is no point
having fortress-like protection against improbable scenarios when there are
much easier ways to get the same information. If you aren't at the level of
pulping (not shredding) all your paper waste, destroying magnetic media before
computer re-sale, and auditing employee finances, then even 768 bit keys
wouldn't be your weakest link.
------------------------------
From: Lassi =?iso-8859-1?Q?Hippel=E4inen?= <[EMAIL PROTECTED]>
Crossposted-To: comp.security.misc
Subject: Re: Medical data confidentiality on network comms
Date: Wed, 30 May 2001 14:19:24 GMT
Roger Fleming wrote:
<...>
> Never disappear? I presume you are talking about emailing it, not posting it
> on a newsgroup. Email will disappear from the net in 5 - 10s unless some
> cracker intercepts and archives it for 30 years in the hope of one day
> decrypting it to blackmailing someone. Not completely impossible, but pretty
> unlikely - especially if it is one of millions of encrypted emails, and has no
> plaintext identifying it as especially interesting.
It will remain in your mail server until you pick it up. In the mean
time the admin of the server may have made a safe copy of its state just
in case. If that safe copy isn't shredded properly... etc <insert here
your favorite amount of paranoia>.
Anyway, the header of the message contains lots of useful stuff, so it
is easy to sort the messages to subgroups according to their potential
amount of interest.
-- Lassi
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: unpredicable random number generator ?
Date: Wed, 30 May 2001 16:24:36 +0200
Sam Yorko wrote:
>
> Mok-Kong Shen wrote:
> >
> > Amaury Jacquot wrote:
> > >
> > > the only known ones are based on counting radio-actives beep on a geiger
> > > counter.
> >
> > Presumably you wouldn't also be able to predict my sequences
> > obtained from casting of dice.
> >
>
> I've been fond of:
> http://www.lavarand.com/
It may be noted that dices can be very cheaply got and
simply used.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Cool Cryptography Website!
Date: Wed, 30 May 2001 16:31:40 +0200
John Savard wrote:
>
> Mok-Kong Shen<[EMAIL PROTECTED]> wrote:
>
> >Be happy that someone values your articles so much that
> >he publishes them verbatim as if these were his own.
> >After all, it assists your purpose of disseminating
> >your views/ideas. (You don't expect revenues from your
> >internet publishing, do you?)
>
> Well, that's why I'm not _too_ upset. But this goes beyond any
> question of revenues, since it could conceivably put my authorship in
> question.
If someone does a verbatim copy, there is good evidence
that he copies from you. If he digests your stuff and
adds something and make it perhaps better, you think you
would be able to more easily convince others that you are
the 'original' author?
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (Mark Borgerding)
Subject: Is this a weakness in RSA key generation?
Date: 30 May 2001 08:02:09 -0700
I found that pgp 2.6.2 may sometimes generate a private exponent n
that does not entirely match the RSA spec (as I know it)
An RSA private exponent d
1) d*e = 1 , mod (p-1)*(q-1)
which implies
2) d*e = 1 , mod (p-1)
3) d*e = 1 , mod (q-1)
pgp seems to occasionally generate a key that satisfies 2&3, but not
1.
I know that stmt #1 implies 2&3, but the reverse is not true.
My question is: is this something to worry about? What effect would
this have on security of the key. I have searched the net briefly for
info on this, but found nothing.
------------------------------
From: "Roger Schlafly" <[EMAIL PROTECTED]>
Crossposted-To: comp.security.misc
Subject: Re: Medical data confidentiality on network comms
Date: Wed, 30 May 2001 14:02:23 GMT
"Larry Kilgallen" <[EMAIL PROTECTED]> wrote > In article
<[EMAIL PROTECTED]>, Samuel Paik <[EMAIL PROTECTED]> writes:
> > Larry Kilgallen wrote:
> >> 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.
> > How? Isn't this yet another attempt at DRM or am I missing something?
> I have no idea what you mean by the abbreviation "DRM", so let me
> try guessing what you may have been trying to say.
DRM = Digital Rights Management. The music industry would
like to use this to sell music over the net, but restrict the user
from giving copies to his friends.
> Certainly anyone along the chain can photocopy a printout without
> control. The control to which I am referring is over _computer_
> access to the records. When I visited my doctor last month she
> pulled up a graph of one of my medical statistics over time. She
> has no direct access to the data -- that access is only from the
> central computer when she logs in. She is not allowed in the
> computer room. I would prefer she logged in with a digital signature
> and released my records to a specialist only with a digital signature,
> but we are not there yet. As I said, n-out-of-m key splitting can
> be used for emergency room scenarios (with extensive alarming and
> notification to the patient and primary care physician).
Once a medico has computer access to a digital record, it is very
difficult to keep him from making unrestricted copies.
------------------------------
** 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
******************************
