Cryptography-Digest Digest #263, Volume #11 Mon, 6 Mar 00 01:13:01 EST
Contents:
Re: are self-shredding files possible? (Michael Sierchio)
Re: Database Cryptography????? (David A Molnar)
Re: Random bit generators ([EMAIL PROTECTED])
Re: THE CIA ... please deport me ... or FBI/NSA or any of people ... please, I have
been in the USA too long .... I am on my way to Vladivostok as I have already going
there since 1990 or so .... it is my train .. your train is HUUHAA .. my train is the
LO ("Dave Francis")
Re: avoid man-in-the-middle known plaintext attack using a stream cipher
([EMAIL PROTECTED])
Re: Cellular automata based public key cryptography (Dr. Yongge Wang)
Re: 'Free' services with tokens/puzzles ("rosi")
Re: RC4 and salt ([EMAIL PROTECTED])
Re: why xor?(look out,newbie question! :) ("r.e.s.")
Re: Best language for encryption?? (wtshaw)
----------------------------------------------------------------------------
From: Michael Sierchio <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,alt.security.scramdisk,comp.security.pgp.discuss
Subject: Re: are self-shredding files possible?
Date: Sun, 05 Mar 2000 18:10:19 -0800
"Ken D." wrote:
>
> does the keyserver machine ever make backups?
Not in the traditional sense -- there is a redundant store,
but it is secured in a manner similar to the email messages.
> is the keyserver and its backups safe from government confiscation?
Any company that is served with a summons, writ, warrant etc. is
barred from continuing to destroy evidence. Nothing can recover a
deleted message, though.
> is the keyserver disk safe from STM analysis?
Yes -- even against finding data left behind on unmapped sectors...
> is the keyserver sysadmin safe from government/legal "persuasion" ?
There are two trust models -- one is the operation of a keystore as
a service bureau -- the other is as an appliance under the control
of a company. It may even be physically located in a remote
locale -- Finland? ;-)
> if you were not targetted, but for some other reason the keyserver was,
> are there trails that point back to you?
Users are "enrolled," and traffic analysis on the email is possible
(the keyserver never sees it). But trolling through the key records
would yield no useful information that could match keys to messages.
> how secure is the communication channel that fetches the key during
> the legit key lifecycle?
Currently it's via SSLv3 or TLSv1, but I think they're looking into something
aking to SKIP or IPSec... The session key is 128 bits. The random
number generator is very secure, and session keys are probably
pretty hard to crack.
> is what's impractical to "brute force" today, going to be impractical
> tomorrow?
Yes. Assume for example the following:
A machine similar to Paul Kocher's DES cracker exists for
Blowfish (unlikely -- BF has an expensive key schedule, something
equivalent to > 500 encryption operations), that such a machine
costs $100,000, and that instead of the 90G keys/s of the Kocher
machine, it can attempt 1T keys/s. Even assuming that Moore's
Law continues to hold, 50 years from now it would still take
more financial and computational power and time than available to conduct
a brute force search for the key.
>
> now, dont get me wrong, it sounds like a very strong solution, but
> it, and nothing, can be perfectly safe forever.
> a better concept to embrace is "safe enough for the value of whats
> being protected for the expected useful life of that protected data"
Such that it would be too expensive and time consuming to the potential
adversary, even if the present value of recovering a single message were
hundreds of millions of dollars.
> paranoia, so many hours of fun!
A plug for Andy Grove's book?
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: Database Cryptography?????
Date: 6 Mar 2000 02:26:26 GMT
Jonathan Katz <[EMAIL PROTECTED]> wrote:
>>I am looking for references of the use of Cryptography in Databases.
>>Thanks for any help,
>> Jerry
> This question is not very specific, but you might want to check out work
> on "Private Information Retrieval", which allows a user to query a
> database but does not let the database know what query the user made.
That's a nice research area -- does anyone use it for anything yet?
where would you implement private info retreival in the real world?
------------------------------
From: [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
Subject: Re: Random bit generators
Date: Sun, 05 Mar 2000 18:53:32 -0800
Guy Macon wrote:
> (please set your line length to 75 characters. It's at 130 now and I have
> to reformat to see what you wrote)
>
> In article <[EMAIL PROTECTED]>,
>[EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote:
> >
> >Another way to express my function is this
> >
> >F(x1, x2, x3) = x1.x3 + x2.~x3
> >
> >It is susceptible to correlation attack since F agrees with x1 75% of
> >the time and with X2 75% of the time. So you may be right that this
> >is not any better than XOR.
>
> I never said that it wasn't any better than XOR, except in one extreme
> test case I designed to make XOR look good. I don't know enough to
> offer an opinion on how good it is. I just want to undersatand the
> advantages, if any. Could you explain what those might be for me?
>
> >I was inpired by the idea of changing the length of the bit string in
> >each round and thought that the formula above would be easier to
> >implement. Well, it was just an idea.
>
> You lost me. I have no clue as to what you are talking about.
I was talking about the topic "How secure is this method" by Erik, 2/7/00
> >BTW, how do you break 3 XORed congruential random number generators?
>
> I hope that you aren't under the impression that I said that I could.
> I am just asking questions to increase my understanding, not making
> claims or trying to prove a point.
------------------------------
Reply-To: "Dave Francis" <[EMAIL PROTECTED]>
From: "Dave Francis" <[EMAIL PROTECTED]>
Crossposted-To:
alt.politics.org.cia,soc.culture.nordic,soc.culture.russian,soc.culture.soviet
Subject: Re: THE CIA ... please deport me ... or FBI/NSA or any of people ... please,
I have been in the USA too long .... I am on my way to Vladivostok as I have already
going there since 1990 or so .... it is my train .. your train is HUUHAA .. my train
is the LO
Date: Mon, 06 Mar 2000 03:10:23 GMT
Old indian proverb.
Money makes iron float.
I just adore that.
Dave
--
[EMAIL PROTECTED] (Email Address)
http://www.angelfire.com/tx2/candyman (Web Page)
503/905-6832 (Fax Number)
"Mark Brooks" <[EMAIL PROTECTED]> wrote in message
news:Payw4.7757$[EMAIL PROTECTED]...
> You have been traveling to Vladivostok since 1990 by train?
> Maybe you should start thinking about booking a flight?...or at least
stick
> your head out of the window to see if a locomotive is attached.
>
> Perhaps the fact that no one has figured out to lay tracks across the
> Pacific ocean is what's slowing you down? One company did try it but the
> weight of the train caused the tracks to flip over. Now that train lies at
> the bottom of the Marianas trench. It was a sad day as the investors lost
a
> lot of money. It was not a total loss as it was discovered that iron rails
> do not float. At the time this was considered a great scientific
> achievement. The man responsible for much of the research, Prof. Murray
> Schwartz received a Nobel peace prize and a teaching position at Princeton
> University for his discovery of the sinking iron phenomonon.
>
>
> "Markku J. Saarelainen" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> >
> > THE CIA ... please deport me ... or FBI/NSA or any of people ...
> > please deport me and replace me .. you can find some Mexican street drug
> > runners or some other people .... I have been tired of being in the USA
> > for years and I do not want to stay here .... I am on my way to
> > Vladivostok as I planned in 1990 and I have already been going there
> > since 1990 or so .... it is my train .. your train is HUUHAA (and a
> > person C2 discussed this HUUHAA train with a person B4 .. :) HAHAHAHAHA
> > ) that was captured by my train .. my train is the LOVE train going
> > through the whole Russia ... and this is my dream ...
> >
> > Yours,
> >
> > Markku
> >
>
>
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: avoid man-in-the-middle known plaintext attack using a stream cipher
Date: Mon, 06 Mar 2000 03:17:12 GMT
In article <89ug0p$dt0$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (David A. Wagner) wrote:
> In article <89udhd$d58$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>
wrote:
> I don't know. I've sometimes informally used the term
> `bit-flipping attack', but I don't know if there is any
> standard accepted name for this type of attack.
It's interesting that there isn't a term. Maybe since this
attack in normal situations is very simple to avoid.
> Ok. Let me just say up front to prevent confusion that
> you can still use a MAC without using a block cipher.
> (I think you probably knew that, and mentioned block cipher
> only by way of example to illustrate the point that this
> must be immediate delivery of each byte, but I wanted to
> mention it just in case.)
You guessed right, and just I'm using the MAC, but only every a fixed
amount of traffic, just to detect the attack. The problem is
that in a remote shell "to detect" is often too late since maybe
some evil command was already executed.
> > In this case
> > you can not use a MAC since you need that every byte reach
> > the destination ASAP.
>
> Ok. You've got a very hard problem on your hands then.
>
> One problem with the slightly more general combiner scheme
> you mentioned (C = Sbox[P] xor K instead of C = P xor K)
> is that it doesn't really prevent these types of `bit-flipping
> attacks'. The attacker can still flip a bit in the ciphertext
> and know that the result will change only a single byte in the
> decrypted plaintext.
I understand, but I can not guess how this is possible.
can you give me some reference? I read about this attack about
some block ciphers and stream ciphers modes (or types) but with
the presence of the non-linear step I can't understand how this
attack works (even if I'm sure you are right).
> In some scenarios, this ability may be useful to the adversary,
> even if he can't predict exactly how the modified plaintext byte
> will change. For instance, imagine a bank sending instructions
> electronically ("transfer $000100.00 from Alice's account to
> Bob's account"). If you flip a bit in the ciphertext corresponding
> to the leading "0" in the plaintext, you will cause the amount
Yep, furtunately in a lot of protocols and even in a remote shell
this attack seems a secondary problem. With the normal "bit-flipping"
attack the attacker can simply guess that (for example) the user
are typing "ls /" and replace it with "rm /", but the ability to
flip some bit seems more acceptable.
> I don't know of any general solution to the problem, and it
> seems to be quite a difficult one.
it's a shame... since in some applications (like the remote shell)
a stream cipher seems very suitable.
Anyway thanks a lot for this help!
antirez
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Dr. Yongge Wang)
Subject: Re: Cellular automata based public key cryptography
Date: 6 Mar 2000 03:37:30 GMT
Tim Tyler ([EMAIL PROTECTED]) wrote:
: Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
: [PK system using CAs]
: : A presumably very dumb question: A cellular automaton is a specialized
: : finite state automaton, isn't it? So wouldn't a (general) finite
: : state automaton be more versatile and hence have the potential
: : of being more complex than a cellular automaton?
: Both FSM and cellular automata are capable of simulating Turing universal
: systems - anything one can do, so can the other.
Are you sure??????
Turing machine can acept any r.e (recursively enumerable, nowadays,
the people in recursion theory like to call this concept c.e.,
that is, computably enumerable) languages, while FSM can only
accept regular languages which are very limited.
You may recall that: FSM << pushdown automaton (context-free language)
<< Turing machines (r.e. language) :-)
: On positive feature of CAs is that they make a positive attempt to reflect
: the "locality" requirement imposed by physics. Signals take a finite
: quantity of time to travel around. To run a synchronous system rapdily,
: do want to mimimise the maximum distance between components. In a
: physical implementation of a 2D CA, on a 2D piece of silicon, all the
: components are the same distance away from one another, and can be updated
: synchronously at a high speed.
: Anyway, I can simulate any FSM in a CA - and as you note - CAs are
: themselves FSMs. The systems don't seem so very different in terms
: of the complexity of the things they can represent.
: --
: __________
: |im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
: Calm down - it's only ones and zeros.
--
======================================================.
Yongge Wang |
Center for Applied Cryptographic Research |
University of Waterloo |
Waterloo, Ontario, N2L 3G1 |
Canada |
Phone:(519)8884567 x 5295 |
[EMAIL PROTECTED] |
http://cacr.math.uwaterloo.ca/~ygwang |
======================================================'
------------------------------
From: "rosi" <[EMAIL PROTECTED]>
Subject: Re: 'Free' services with tokens/puzzles
Date: Sun, 5 Mar 2000 23:01:34 -0500
Ville wrote in message ...
>On Sat, 4 Mar 2000, Adam Durana wrote:
>
>> I don't see RSA's solution really solving the problem. Personally I
think
>> the folks at RSA saw how much attention the media was giving these recent
>> denial of service attacks and hoped by claiming they had a solution to
the
>> problem, they would recieve some publicity. There are a few reasons why
I
>> don't think thier puzzle system will work. [...]
>
>I have to pretty much agree.
>
>Aside from your technical points regarding to puzzles as a DoS-prevention
>measure, it's good to keep in mind the current nature of the distributed
>attacks: CPU and bandwidth are already unlimited or soon about to become
>that for the attacker.
>
>There is no reason for them not to succeed in a pure resource-exhaustion
>attack. I recently had to deal with PPark (a Windows virus/trojan). As I
>pointed out on a few mailing-lists, there are ~90 000 infected boxes
>currently active. If you get 90 000 boxes number-crunching (and make the
>connections look exactly like the normal Windows-initiated ones), there
>is not exactly a thing the remote end could do to stop it - or to even
>slow the attack down. (attempting to route them dynamically to null
>showed us a quick way to a table overflow...)
>
>Oops, going off topic.
>
>To stay on the subject, I'd just add we were not looking at this as a
>direct DoS-prevention method. More as a way of rewarding the people
>more committed to the project or that have been around longer. Not only
>that, but I also found this something that could be interesting to
>experiment with as it still seems a bit unexplored.
Could be interesting (and not otherwise as I thought without giving it much
of a thought). I just wonder, how much interest would there be out there?
You guys are wonderful. I agree. There does not seem to be a solution.
A partial one can be at best a maybe to the mess I term 'legitimated open
access'. To me, there is not much room we can play around. One thing
kind of obvious to me is that we have to 'slow all requests originators
down' in proportion to the number of requests originated.
Once again, do you think that there would be any interest in a partial
solution that could practically ease A LOT of the pain?
Thanks
--- (My Signature)
>
>
>--
> Ville([EMAIL PROTECTED], 'Cryptlink Networking);
>
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: RC4 and salt
Date: Mon, 06 Mar 2000 04:25:50 GMT
David A. Wagner <[EMAIL PROTECTED]> wrote:
: In article <89oajs$ajf$[EMAIL PROTECTED]>,
: Tom St Denis <[EMAIL PROTECTED]> wrote:
: > In article <Pqwv4.2411$[EMAIL PROTECTED]>,
: > [EMAIL PROTECTED] wrote:
: > > I have a question about implementing "salt" with RC4. Basically, what
: > > is the standard method?
: >
: > Just append a 32-bit tag to the session key when you encrypt/decrypt.
: > You can even use the time() function if you don't want to code anything
: > else. As long as each session key is unique [which is possible in this
: > case].
: No, that's not the standard method (I hope not, anyway!), and to me it
: sounds scary and quite possibly insecure. (See Roos' RC4 analysis.)
: Go read how SSL/TLS do it. Basically, they append a 32-bit unique tag
: to the master key and *hash* them to get a RC4 session key.
Thank you very much for this! You led me right to the thing I've been
looking for but been unable to find.
Charles R. Wright
------------------------------
From: "r.e.s." <[EMAIL PROTECTED]>
Subject: Re: why xor?(look out,newbie question! :)
Date: Sun, 5 Mar 2000 21:20:12 -0800
A small slip: You forgot to say that A and B are assumed to be mutually =
independent -- the general result doesn't hold otherwise. (And that's =
the technical meaning of Guy's proviso "not derived from".)
--=20
r.e.s.
__________________
"Mok-Kong Shen" <[EMAIL PROTECTED]> wrote in message =
news:[EMAIL PROTECTED]...
| Guy Macon wrote:
| >=20
|=20
| > I have read (but lack the background to verify for
| > myself) that a true random bytestream xor'ed with
| > any bytestream not derived from the true random
| > bytestream results in a true random bytestream.
| >=20
| > Does addition of bytes modulo (2^8) have this same
| > property? Is there a reference that I can point to
| > if someone doubts this?
| >=20
| > Can I extend the idea and add nybbles modulo 16 or
| > 16 bit words modulo 65536? For bits I believe that
| > xor and addition modulo 1 act the same.
|=20
| If by 'true random' you mean 'impossibility of being predicted',
| then I suppose the proof is straightforward. Let A be any sequence,=20
| B be an unpredictable sequence, and C be their modulo sum, i.e.
|=20
| C =3D A + B mod n
|=20
| Suppose C were predictable. Rewrite the above to
|=20
| B =3D C - A mod n
|=20
| Now the left side is unpredictable, but the right side is predictable.
| This contradiction establishes the result.
|=20
| But I suppose what you read previously is a theorem regarding
| distributions. It says that the modulo sum of an arbitrary
| distribution and a uniform distribution results in a uniform
| distribution. The result is due to Wichmann and Hill who stated
| the theorem for continuous distributions in a paper in Applied
| Statistics. A rigorous proof appeared later in a paper by=20
| someone else for which I don't have the reference at hand. But=20
| in the discrete-valued case as in the above, one can in fact
| prove it rather simply. For illustration, let's consider n=3D4.=20
| Let a0, a1, a2 and a3 be the frequencies of 0, 1, 2, and 3 of A,
| and similary b0, .... and C0, ..... Now we have, for example,
|=20
| c3 =3D a0*b3 + a1*b2 + a2*b1 + a3*b0
|=20
| Since B is uniform, we have
|=20
| c3 =3D (a0 + a1 + a2 + a3)/4 =3D 1/4
|=20
| Thus C is uniform.
|=20
| If one considers a continuous distribution to be the limiting
| case of a discrete-valued distribution, one can arrive at
| the original result of Wichmann and Hill from the above. (The
| proof in the other paper mentioned above is a bit more involved,
| as far as I can remember.)
|=20
| M. K. Shen
| ---------------------------
| http://home.t-online.de/home/mok-kong.shen
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Best language for encryption??
Date: Sun, 05 Mar 2000 23:12:40 -0600
In article <[EMAIL PROTECTED]>, "Douglas A. Gwyn"
<[EMAIL PROTECTED]> wrote:
> wtshaw wrote:
> > Programing has one effect, it either does what you want it to do,
> > or it doesn't; all else is unimportant.
>
> Wrong! There are a *lot* more important factors in programming
> than just that one. The attitude you expressed was responsible
> for major disasters in software during the late 1960s and early
> 1970s, to the extent that it was generally considered a crisis
> situation. Out of that crisis rose the development of software
> engineering as a disciplined activity. One of the most readable
> surveys of different approaches to this area is P.J. Plauger's
> book "Programming on Purpose", which is mainly reprints of some
> of his magazine columns.
Doing what you want it to do can be rather a big load, not one factor.
Programing is meant to facilitate computers being useful, which is open to
individual interpretation.
Engineering disasters may fall under the category of not being as
successful as planned. Supposedly software designers, language mediators,
and users are to have big reasonable goals as well as small ones, and
should not settle for less than comprehensive determination that possible
errors are minimized with good safety margins.
Software is a tool, to learn through, to increase efficiency, to help you
achieve and experience what you want and/or need. People that are
shortsighted that make important decisions do not tend to answer a few
critical long-term concerns.
Bad authoritarianism can contribute to problems by subverting good ideas
to ridicule in the spirit of there was no prblem before and you are not in
the position to know or do anything. It is rather scientifically
offensive to place ego above openmindedness, denying useful information
because evolutionary views of reality make you uncomfortable. It seems
that this is what you should be complaing about.
--
Imagine an internet on an up and up basis, where there are no subversive techniques to
rob a person of their privacy or computer
functionality, no hidden schemes used to defraud anyone. :>)
------------------------------
** 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
******************************
