Cryptography-Digest Digest #261, Volume #11 Sun, 5 Mar 00 19:13:01 EST
Contents:
Re: avoid man-in-the-middle known plaintext attack using a stream cipher
([EMAIL PROTECTED])
Re: Explaination of method question (Nemo psj)
Database Cryptography????? (Jonathan Katz)
Re: are self-shredding files possible? (Michael Sierchio)
Re: avoid man-in-the-middle known plaintext attack using a stream cipher ("Joseph
Ashwood")
sci.crypt Cipher Contest ("Adam Durana")
Re: why xor?(look out,newbie question! :) ("Joseph Ashwood")
Re: 'Free' services with tokens/puzzles ("Joseph Ashwood")
Re: why xor?(look out,newbie question! :) ("Joseph Ashwood")
Re: are self-shredding files possible? ("Joseph Ashwood")
Some people tried to call me day and night (Fri to Sat), but at this ("Markku J.
Saarelainen")
Re: are self-shredding files possible? ("Ken D.")
Oh Look! 208.170.158.15 is an Open NNTP SERVER THAT ALLOWS POSTING TO ANY NEWSGROUP
(OPen Server)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Re: avoid man-in-the-middle known plaintext attack using a stream cipher
Date: 5 Mar 2000 23:04:44 GMT
I would suggest an error propagating protocol. If you use e.g. WeakCipher
which based on a "P-CFB" mode (is it really called that?) you will neither
increase the bandwidth nor have to wait for a signature, and the entire
message after any altered bit will be complete gibberish. A "bit flipping
attack" won't work either.
The trick is to save the encryption of the feedback buffer, and to use a
"misbehaving" permutation as block cipher. I haven't done any calculations,
but I guess a 16-bit block cipher might do as well as long as it shares the
mentioned properties with WeakCipher. A 16-bit block cipher might be stored
as a SBox consisting of a 65536 word vector, so I guess it would be fast
enough.
In a previous article, <[EMAIL PROTECTED]> writes:
>In article <89udhd$d58$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
>> Sorry, what's the right name for this kind of attack?
>
>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.
>
>> No, I cant [... use a MAC ...]
>> A stream cipher is very useful to encrypt a socket in the
>> case of a telnet-like connection since if you use a block
>> cipher you needs to spent more bandwidth.
>
>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.)
>
>> 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.
>
>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
>transferred to be increased dramatically from $100 to hundreds
>of thousands of dollars. You can imagine that Bob might have
>considerable incentive to mount such an attack. It seems to be
>true that the attacker can't predict exactly what that leading
>"0" will turn into after the attack, but he probably doesn't
>care -- no matter what it turns into, Bob will have made a
>considerable profit.
>
>I don't know of any general solution to the problem, and it
>seems to be quite a difficult one.
----- Posted via NewsOne.Net: Free Usenet News via the Web -----
----- http://newsone.net/ -- Discussions on every subject. -----
NewsOne.Net prohibits users from posting spam. If this or other posts
made through NewsOne.Net violate posting guidelines, email [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Nemo psj)
Subject: Re: Explaination of method question
Date: 05 Mar 2000 23:16:39 GMT
Ok sure those reasons seem good enough although i have no idea as to how i
would explain the algorithm in those terms. I have a sneaking suspision that i
wont be able to.
------------------------------
From: Jonathan Katz <[EMAIL PROTECTED]>
Subject: Database Cryptography?????
Date: Sun, 5 Mar 2000 18:17:54 -0500
>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.
======================
Jonathan Katz
[EMAIL PROTECTED]
------------------------------
From: Michael Sierchio <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: Re: are self-shredding files possible?
Date: Sun, 05 Mar 2000 15:13:47 -0800
Joseph Ashwood wrote:
>
> To consider such is an excercise in faith, to practice such
> is foolishness. You have no way of stopping an individual
> from taking your code, and debugging it. From there it is a
> simple matter to grab the key, or create an altered client
> that will permanently store the keys.
Debugging it? most folks would be grateful for that ... ;-)
As for the rest of your comment, there are definitely ways of
protecting against tampering the code itself -- you could
attempt to build a client that speaks the appropriate
protocol, but wouldn't be able to authenticate yourself or
pass the first challenge. And since you either have to be
the sender or recipient of the message in order to form a
valid key retrieval request, you'd have to encourage one
of your remaining correspondents to issue something incriminating
or embarrassing. They should be duly warned by now.
Also, there are methods of detecting cheaters in secret sharing
schemes -- you might benefit from doing some reading.
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: avoid man-in-the-middle known plaintext attack using a stream cipher
Date: Sun, 5 Mar 2000 15:07:39 -0000
Step one would be to choose a cipher more suited to your
needs. There is no requirement that a stream cipher operate
on nothing larger than 1 byte, there is also no requirement
that a stream cipher use XOR. One could, for example, take
your same pRNG and use every 56bits as a key for DES, or
IDEA, or Twofish, Serpent, MARS, Rijndael, etc. It is simply
non-classical to do such.
Joe
<[EMAIL PROTECTED]> wrote in message
news:89tu0t$2uc$[EMAIL PROTECTED]...
> It's well known that in some case stream ciphers
> are vurnerable
> to a "meet in the middle known plaintext" attack.
> This means that
> if P xor S = C the attacker that known P can
> obtain S and replace
> P with an arbitrary P'. How is possible to avoid
> this problem?
> I'm not able to find some reference in litterature
> but it *seems* that
> if before to ecrypt every byte of P I perform some
> simple nonlinear
> transformation or some operation from a different
> algebraic group
> this attack become not possible. For example using
> an 8x8 sbox
> I encrypt with C = sbox[P] xor S
> and decrypt with P = sbox[C xor S]
> (This seems to work even using for example
> addition modulo 256)
> If This is secure is very useful in order to
> encrypt for example
> a TCP connection if you fear hijacking but I don't
> known
> if I'm right since I'm not a cryptographer.
> The sbox can be obtained using the first bytes of
> the keystream
> and updated every X bytes, I hope this don't
> violate the
> U.S. patent 4,979,832
> (http://www.io.com/~ritter/#DynSubTech).
> Thanks for the attention. Comments are very
> appreciated!
>
> (sorry if you'll recive this message twice)
>
> antirez
>
> email: antirez@linuxcare<dot>com
>
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
------------------------------
From: "Adam Durana" <[EMAIL PROTECTED]>
Subject: sci.crypt Cipher Contest
Date: Sun, 5 Mar 2000 18:21:13 -0500
I see a lot of ideas for encryption algorithms posted to sci.crypt all the
time, and I know several regular posters have thier own ciphers they have
developed. Since most of us are amateur cryptographers, and study
cryptography for fun. I thought it might be fun to have a contest such as
AES. And at the end we could select the best cipher based on the criteria
we decide on. So if anyone is interested in participating, we could start
to draw up the criteria for the contest entries.
The only thing I can think of right now that should be in the criteria is
that an entry should be a block cipher. Ofcourse other details such as key
size, block size and etc will need to be decided on.
So if you have any ideas for the basic criteria for an entry post it, and I
will do my best to keep a record of all the ideas. Eventually we will have
to decide on a solid cirteria for entries, which will be hard without a
doubt, but we will see how it goes.
- Adam Durana
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: why xor?(look out,newbie question! :)
Date: Sun, 5 Mar 2000 15:19:05 -0000
> Does addition of bytes modulo (2^8) have this same
> property? Is there a reference that I can point to
> if someone doubts this?
While I never seem to have time to perform absolute proofs.
The basics of proving that XOR operates that way is as
follows:
For all pairs (C,P) where C and P are of length L
There exists a key K (also of length L) such that P XOR K =
C
Therefore given a true random K, C will have a random
distribution, and therefore be random.
The same follows for addition, but will be very difficult to
prove for something more complex. I am sure it will fail for
DES, but other ciphers may not fail.
Joe
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: 'Free' services with tokens/puzzles
Date: Sun, 5 Mar 2000 15:26:04 -0000
I can easily alter the attack to address that. I take the
same real client A, place it in my network N. In my network
N I have the following:
K other systems that I wish to have access to the resource
being marshalled by participation.
NAT a network address translation box, the will map my K+1
machines to one address.
[insert extra measures as needed]
I now have access to the resource from K machines that would
otherwise not have access. Alternately if the resource is
marshalled by the number of machines perceived, I could
create a rogue client inside of a NAT box that goes the
other direction (1 to many), and use K NAT boxes (probably
inside my K machines) to address the issue. Doing either of
these I isolate A, or use a rogue A that still performs the
work.
I have found a rather kludgy solution, that many clients
won't like. Allow them access to the resource based on the
amount of work they do, if AOL writes the program into their
client, and AOL performs 90% of the operations, then AOL
gets 90% of the resources (since the resources are transient
it would often not be necessary to place the restrictions,
but once the pipe is full the cuts could be severe).
Joe
<[EMAIL PROTECTED]> wrote in message
news:89ueu0$620$[EMAIL PROTECTED]...
> You are right, but such attacks are, in a sense, a smaller
problem since it
> is in the best interest of the clients to avoid them.
Consequently, the
> service provider will in this case not have to come up
with a protocol which
> is tamper resistent even though it is open source and
explained in detail. I
> guess a conventional digital signature scheme would be as
good as any
> solution. (Unless A has only made contact with B from the
start, but if this
> is so A must either be really stupid or probably sooner
than later break all
> contact with B.)
>
> In a previous article, "Joseph Ashwood"
<[EMAIL PROTECTED]> writes:
> [---]
> >In addition I realized that both of our methods are
subject
> >to a man in the middle attack, as follows:
> >download real software on client A
> >create fake software on client B
> >make A think B is the server
> >Whenever A talks B routes the data to the server
> >Whenever the server talks B filters it and sends the data
to
> >A
> >Whenever B wishes to use the connection B sends to the
> >server.
> >
> >If you want to avoid attacks like this, then neither of
the
> >proposed methods will work.
> > Joe
> >
> >
>
>
> ----- Posted via NewsOne.Net: Free Usenet News via
the Web -----
> ----- http://newsone.net/ -- Discussions on every
subject. -----
> NewsOne.Net prohibits users from posting spam. If this
or other posts
> made through NewsOne.Net violate posting guidelines, email
[EMAIL PROTECTED]
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: why xor?(look out,newbie question! :)
Date: Sun, 5 Mar 2000 15:27:08 -0000
As others have said, XOR is used because it is faster than
addition, and your security relies solely on the strength of
you pRNG. You might also wish to look into using operations
outside of the norm, especially if you seek to avoid an
insertion attack. I mean by this that you take a very good
pRNG, and use a strong cipher. For a stream cipher it will
probably increase security against most attacks, but in a
true OTP the security would likely be lowered (see my
response to another post in this thread for details).
Joe
<[EMAIL PROTECTED]> wrote in message
news:89tvbk$3nk$[EMAIL PROTECTED]...
> I played with idea of making my own encryption
> algorithm(haven't we all..),a basic thing,just for
> fun,and I wanted to base it on pseudo-random
> number generator,and using password for creating
> seed.It would do something like:
> cypher=(text + rnd)mod 256
> on each byte of plain-text.Theoreticly,it should
> produce uniform distribution of same interval as
> rnd number,right?
>
> Now some friends of mine tell me: No,don't use
> that,use xor,everybodies using xor....
> Sooo,now I wonder why is it,really,that there's so
> many algorithms out there that choose to use xor
> rather than some other method?Is it just for
> speed,or because you can use a single function for
> both encrypt and decrypt or there's something
> more to it?
>
> Thanx on reading this,
> Ivan
>
> ps.And when you already here,could you give me a
> short comment on my initial idea of
> encryption.What would be your line of attack,if
> U need to decrypt it?
>
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: are self-shredding files possible?
Date: Sun, 5 Mar 2000 15:31:58 -0000
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
> Debugging it? most folks would be grateful for that ...
;-)
Only to look at the keys, which would void your entire
approach.
> As for the rest of your comment, there are definitely
ways of
> protecting against tampering the code itself -- you could
> attempt to build a client that speaks the appropriate
> protocol, but wouldn't be able to authenticate yourself
or
> pass the first challenge. And since you either have to be
> the sender or recipient of the message in order to form a
> valid key retrieval request, you'd have to encourage one
> of your remaining correspondents to issue something
incriminating
> or embarrassing. They should be duly warned by now.
You obviously don't do much programming, at least none
security related. The most general argument is that the
checks exist in the OS to detect debuggers. So as I stated
probably a month ago, run linux, on top of linux run VMWare
inside VMWare run whatever OS I need to to run your program,
attach a debugger to VMWare. Problem solved, you can't
detect the debugger, because it's not running on your OS,
and within it's environment it is running correctly.
> Also, there are methods of detecting cheaters in secret
sharing
> schemes -- you might benefit from doing some reading.
You would have to detect a correctly operating client, as a
rugue client. It simply can't be done. Perhaps you would
benfit from actually trying to do it.
Joe
------------------------------
From: "Markku J. Saarelainen" <[EMAIL PROTECTED]>
Crossposted-To:
alt.politics.org.cia,soc.culture.russian,soc.culture.soviet,soc.culture.nordic,soc.culture.usa,soc.culture.europe,soc.culture.ukrainian
Subject: Some people tried to call me day and night (Fri to Sat), but at this
Date: Sun, 05 Mar 2000 23:49:02 GMT
2441 INVERLOCH CIR, DULUTH, GA, 30096-6257, USA
http://www.mapquest.com/
------------------------------
From: "Ken D." <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Crossposted-To: alt.security.pgp,alt.security.scramdisk,comp.security.pgp.discuss
Subject: Re: are self-shredding files possible?
Date: Mon, 06 Mar 2000 00:03:39 GMT
does the keyserver machine ever make backups?
is the keyserver and its backups safe from government confiscation?
is the keyserver disk safe from STM analysis?
is the keyserver sysadmin safe from government/legal "persuasion" ?
if you were not targetted, but for some other reason the keyserver was,
are there trails that point back to you?
how secure is the communication channel that fetches the key during
the legit key lifecycle?
is what's impractical to "brute force" today, going to be impractical
tomorrow?
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"
i'd probably use the keyserver to secure ALREADY encrypted documents,
and then encrypt that result so its not obvious the keyserver needs
to be hunted down... :) :)
paranoia, so many hours of fun!
-ken
Michael Sierchio wrote:
>
> Paul Koning wrote:
>
> > ...If you
> > have a backup copy the message clearly hasn't disappeared. If you have
> > a backup copy plus a search warrant, clearly the message will be
> > produced even if the supposed time period is gone.
>
> You are simply mistaken -- a backup copy, as well as all other deleted
> or undeleted copies, is of no avail. Once the expiry time has arrived
> the key is securely deleted from the keyserver. A brute force attack to
> recover the plaintext is quite infeasible. So, the bits may still be
> there, but the DOCUMENT has disappeared. No court order or coercion
> can recover the message, either. Removing the disk and subjecting it
> to STM analysis would be a waste of time.
>
> > The reality is that what's being asked for is impossible.
>
> Nope. It really works...
------------------------------
From: [EMAIL PROTECTED] (OPen Server)
Subject: Oh Look! 208.170.158.15 is an Open NNTP SERVER THAT ALLOWS POSTING TO ANY
NEWSGROUP
Date: Mon, 06 Mar 2000 00:09:10 GMT
testing 1 2 3........
------------------------------
** 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
******************************
