Cryptography-Digest Digest #897, Volume #13 Wed, 14 Mar 01 14:13:01 EST
Contents:
Re: Crypto idea (br)
Re: qrpff-New DVD decryption code (Jean-Pierre Moreau)
Re: OverWrite: best wipe software? (Richard Heathfield)
Re: qrpff-New DVD decryption code (Darren New)
Re: OverWrite: best wipe software? (Darren New)
Re: Instruction based encryption (Matthew Skala)
Re: GPS and cryptography (Darren New)
Re: qrpff-New DVD decryption code (Joe H. Acker)
Re: Basic Cryptoanalysis (Daniel)
Re: Is this book interesting (Daniel)
----------------------------------------------------------------------------
From: br <[EMAIL PROTECTED]>
Subject: Re: Crypto idea
Date: Wed, 14 Mar 2001 12:11:04 -0400
My idea it's like someone who don't know wich language I used.
But once the plain text deciphered with the appropriate key every human
being can read and understand Ay lovv u or Ilauv yu etc...
Before attack, cryptanalisis is helpless.
David Schwartz wrote:
>
> "Trevor L. Jackson, III" wrote:
>
> > No, anyone who was at least as intelligent as the intended receiver would be able
> > to read messages.
>
> I think his argument is basically that it would be more difficult to
> brute-force a key if you had no idea what the 'plaintext' looked like.
> However, there are so many flaws in this argument one hardly knows where
> to being pointing them out. The most obvious are:
>
> 1) You can brute-force PK without knowing what the plaintext looks like
> anyway. For example, brute-forcing RSA usually involves factoring a key,
> which has nothing to do with the plaintext (or ciphertext for that
> matter).
>
> 2) If your biggest vulnerability is that someone might exploit some
> knowledge of your plaintext to brute force a key, then you've got a damn
> good encryption system. I mean, that's the goal that we shoot for.
>
> 3) Many of the tricks you suggest rely upon alternate alphabets. You
> would have to communicate the alphabet to the recipient in order for him
> to have any hope of decoding the messages, thus decreasing their value
> for obfuscation.
>
> 4) Such encryption would be extremely hard to use. You could justify
> this difficulty of use if some extra security were provided for
> applications that already had extremely high security. But there's no
> such advantage. You could just as well take however much difficulty you
> think this adds to brute-forcing, convert it into bits, and make your
> key that much longer.
>
> 5) You either trust your encryption or you don't. If your encryption is
> weak, at best this will give you a false sense of security.
>
> 6) This relies extensively on humans, by far the least reliable piece
> of any cryptosystem.
>
> DS
------------------------------
Subject: Re: qrpff-New DVD decryption code
From: Jean-Pierre Moreau <[EMAIL PROTECTED]>
Date: Wed, 14 Mar 2001 17:18:40 GMT
A consideration that decided me to copy and download copyrighted music
is the powerful legal and media propaganda from 'the music industry'.
Before, I did bought what I wanted to possess.
In a market economy, prices should be down when, say, new technologies
enable production at lower prices. New technologies now permit very
cheap diffusion of music. Powerful Music Conglomerates are only
distributors, even if they incidentally own rights on music by
contracts. So how is it that we pay, say 5$ or 12$ (on, say, 15$ for a
a music CD) to the distributor, when the actual cost of distributing
by new means is much cheaper, say 0.25$ ?
Because market economy fails when there are Monopolies (or equivalent
to monopolies). When they exist, they nearly define legality (legality
differs from moral/ethical consideration, as Douglas A. Gwyn maked the
remark).
The only defacto way to defeat it is being illegal.
Why people and small companies working in an obsolete technology
should go in something else, but not very large Corporation? Because
they are Monopolies.
--
Jean-Pierre Moreau,
nouser@inexistant (s/nouser/jpm-qc/; s/inexistant/iquebec.com/).
------------------------------
Date: Wed, 14 Mar 2001 16:14:38 +0000
From: Richard Heathfield <[EMAIL PROTECTED]>
Crossposted-To: alt.hacker
Subject: Re: OverWrite: best wipe software?
Anthony Stephen Szopa wrote:
<snip>
> Let me ask you then, using OverWrite and my procedure of a dedicated
> hard drive partition, etc., why will not the desired file be
> thoroughly overwritten? Give us just one objection and we will
> pursue it like a pack of dogs pursues the fox.
No objection, just a request. Could you publish the source code, please?
The binary wouldn't run on my OS even if I asked it to, and
disassembling or otherwise reverse-engineering it seems like a lot of
unnecessary work to me.
--
Richard Heathfield
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R Answers: http://users.powernet.co.uk/eton/kandr2/index.html
------------------------------
From: Darren New <[EMAIL PROTECTED]>
Subject: Re: qrpff-New DVD decryption code
Date: Wed, 14 Mar 2001 17:36:49 GMT
Douglas A. Gwyn wrote:
> Matthias Bruestle wrote:
> > It is theft if the legal system thinks it is theft.
> Theft is a moral/ethical concept, logically prior to legality.
I don't think the question is whether theft is a moral concept prior to
legality. (I believe it is.) I think the question is more whether
intellectual property can be stolen in the moral sense rather than the
strictly legal sense. If I buy the computer and the blank CD and the
commercial CD, and then I make a copy of the commercial CD on the computer
by rarranging the tracks, I have *created* something new (the
no-longer-blank CD), not stolen it.
Being deprived of income is not always the same as theft. In the above case
it is, because that's how the law defines it. But whether it's a moral
question is more debatable. (And of course, debating morals is a waste of
time, since morals aren't based on logic.)
Consider if you park, and the meter runs out, but you don't get ticketed. Do
you feel you've stolen something from the parking authority? Do you
voluntarily go to the local police and pay them the $15 you would have had
to pay had you been noticed by the meter maid? :-)
--
Darren New / Senior MTS & Free Radical / Invisible Worlds Inc.
San Diego, CA, USA (PST). Cryptokeys on demand.
------------------------------
From: Darren New <[EMAIL PROTECTED]>
Crossposted-To: alt.hacker
Subject: Re: OverWrite: best wipe software?
Date: Wed, 14 Mar 2001 17:49:20 GMT
Anthony Stephen Szopa wrote:
> I think you have not read my procedure thoroughly or understood it
> completely.
>
> "A dedicated hdd partition will still not help the case for when
> the hdd compresses sectors."
>
> You have just made a blanket statement with no support for it other
> than to say that it is so. Why won't my procedure and software work
> with a compressed hard drive?
I don't think it's up to him to say why it doesn't work. If the drive is
compressing data, the data you write might not fill up the drive, leaving
old data left over. So how do you deal with this? He doesn't have to give
evidence that compression will screw your code. You have to give evidence it
won't.
If you go buy a car (say) and give the salesman a check, he doesn't have to
prove the check will bounce to avoid giving you the car. You have to prove
the check won't bounce to get the car. Why? Because the salesman has the
car.
If you're trying to get other people to use your software, *you* need to
convince *them*.
> What does this do for you? Primarily it does two things. First it
> pretty much assures you that any processing you do on this dedicated
> hard drive H:\ will be confined to drive H:\.
"Pretty much"? OK, so isn't this a blanket statement with no support for it
other than to say it is so?
I think that's what people object to.
> Not only is the data
> processing confined to drive H:\ but it is confined to the free space
> where you deleted TFiles 2 - 13.
So what are TFile1 and TFile 14 for? Why create the TFiles at all?
Sounds like you set some parameters and then arrive at your conclusion but
fail to explain the chain of events or logic that allowed you to arrive at
your conclusion. [sic]
> Again, you set some parameters then arrive at your conclusion but
> fail to explain the chain of events or logic that allowed you to
> arrive at your conclusion?
> The user can set any sleep suspension from 2 - 120 seconds between
> passes that include fflush, fclose, etc.
What if the cache is held indefinitely, until it's needed to be written, and
the cache is bigger than the disk space? You still haven't answered that.
> Additionally, you can see,
> hear, and feel the hard drives being accessed.
No, *you* can, on *your* computer. What he imagines is going on here is that
his computer works differently from yours.
> So, come on, now, tell us why it won't work if your "computer's
> cache keeps blocks in memory for a very long time" and "and has a
> very large cache (maybe even larger than the dedicated partition)."
Well, if the computer caches everything for 90 minutes, and the cache is
bigger than the partition, then it won't get written out to disk for 90
minutes, after which your code has exitted. Hence, your code writes to the
disk once. On that computer. Maybe not yours, but on that one.
> Does what you say matter if the hard drives have been written to
> and the file overwritten pass after pass?
No. But what we're discussing is whether it *is* overwritten after each
pass. You've given zero evidence that it will be on any computer other than
yours.
--
Darren New / Senior MTS & Free Radical / Invisible Worlds Inc.
San Diego, CA, USA (PST). Cryptokeys on demand.
------------------------------
From: [EMAIL PROTECTED] (Matthew Skala)
Subject: Re: Instruction based encryption
Date: 14 Mar 2001 09:38:13 -0800
In article <q5Fr6.1312$[EMAIL PROTECTED]>,
Michael Brown <[EMAIL PROTECTED]> wrote:
>"Matthew Skala" <[EMAIL PROTECTED]> wrote in message
>news:98lr8n$jmi$[EMAIL PROTECTED]...
>> One problem with this scheme is that it will tend to be highly linear; no
>How do you tell this? I actually tried to avoid linearness through inclusion
>of rotation and use of the ciphertext. Subtraction and addition are highly
>(100%) linear though, so maybe should be replaced in the table.
As I understand it, the rotation is determined by bits in the *key*,
right? So it'll be the same from one byte to the next, at least until the
next "mash". Over the short term, the amount of rotation can be treated
as constant. In that case, the output of the rotation is completely
linear; it serves only to select *which* bits go into the linear
combination. Making the rotation truly data-dependant instead of
key-dependent might help a little, but you shouldn't depend on
data-dependent rotations for all your nonlinearity; their performance has
been a little disappointing (I think RC5 is a cipher where there've been
some results against the data-dependent rotations, not fatal to the entire
cipher but its overall design is a lot stronger than yours...). One
problem with, for instance, taking bits out of the plaintext instead of
the key to choose the amount of rotation, is that the plaintext may be
guessable or controllable by the attacker.
Including ciphertext in inputs to the linear functions doesn't make things
any less linear if the ciphertext is a linear function of the plaintext to
begin with. It also doesn't help much when the preceding ciphertext is
*known*... which it almost always is under any reasonable threat model,
except maybe in the first block. Finally, even if you include *some* bits
that are unknown, that doesn't change the fact that your output is
well-approximated by a linear function; it's just that it's a linear
function with some of the inputs unknown. That may still be an
information leak useful in cryptanalysis. For instance, there could be
a different leak allowing me to guess the values of the unknown bits. It
needn't be infallible - even if I can only make the odds of guessing an
unknown bit 51 to 49, or 501 to 499, or 5001 to 4999, (instead of
perfectly 50/50), I can run statistics over a lot of plaintext and
ciphertext and use it to my advantage.
>Weak keys are definately a problem. However, I think good design of the
>instruction table (the one that I posted is plain shocking for weak keys)
>detecting and avoiding weak keys should be relatively easy.
I think if you make your instruction table orthogonal enough that you can
automatically recognize weak keys, then you will lose a lot of what is
interesting about having an "instruction"-based cipher. Examining a
computer program and figuring out what it does is a difficult
problem; that's part of the point of Turing's work on automata. If you
limit your language to the point where it can only describe machines that
can be tested by other machines, then your language will necessarily be
unable to express a lot of interesting concepts. On the other hand, if
you make your language expressive enough to be difficult to analyze (which
seems to be what you want for security of this kind of cipher) then it
will necessarily be *difficult to analyze*, and create a weak-key problem.
>Actually, it is worse. The key can (and will after a maximum of 1.5k of
>data) get stuck to zero, regardless of the input data. This is a serious
>problem that I really should have picked up upon. A few changes definately
>need to be made to the key mashing ...
I don't know if you're familiar with the famous "random number generator"
story in Knuth... they had a random number generator that took a decimal
number with I think 8 digits, and separated the digits out and did various
things, including interpreting the digits as instructions in a scheme a
little bit like yours, eventually spitting out a new number, on which
they'd then apply the same procedure. The idea was that this was supposed
to be "very random". But it turned out to usually get stuck, no matter
what the initial value, on just one number that would happen to produce
itself under the complicated produced they had adopted.
It appears to be a fact of nature that schemes of this general nature,
where you crunch a number through some very complicated function
repeatedly, *often* have a tendency to get stuck in small loops. If you
are designing such a scheme, it's necessary to argue mathematically that
that's unlikely to happen, not just give it a big internal state and hope.
>I would have thought that you would always need to know the 32 bytes before
>the bit that you know to figure out the cipher state at the start. Then you
>need to know another 32 bytes etc. Could you please explain a little here
>(or just point me in the right direction?
Well, if the key gets stuck into all zeroes, and the plaintext is all
zeros, then the ciphertext is all zeroes. Sequences of all zeroes are
pretty common in many kinds of plaintext. If I'm the attacker and I see a
long stretch of zeroes (a few thousand bytes) in the ciphertext, I'm faced
with two possibilities:
A. there were all zeroes in the plaintext, and the key is stuck in a state
of all zeroes
B. the plaintext and key are something else which just happens to produce
zeroes in the ciphertext, and this state of affairs has persisted,
through random chance, over thousands of bytes
In the absence of other strange behaviour in your cipher, option B is
astrononmically improbable. Even if the cipher does have other strange
behaviour that would make option B possible too, option A still seems a
lot more probable. So when the run of zeroes ends with nonzero
ciphertext, I can easily guess my "32 previous bytes": they are all zeroes!
Even if you apply some sort of band-aid to the cipher to eliminate the
special zero-related behaviour, the basic rule that "complicated functions
of this general nature often get stuck in small loops" will still apply,
and will create a similar kind of problem - some simple patterns in the
plaintext, such as long stretches of zeroes, will tend to create specific
recognizable patterns in the ciphertext, and those patterns will provide
clues to the unknown "state" of the cipher at the end of the pattern.
This is a sensitive subject, but the same kind of weakness was helpful in
attacking the Cyber Patrol blocking list cipher; plaintext patterns showed
through in the ciphertext. We never did end up really cryptanalysing that
cipher because reverse engineering of the secret algorithm proved easier;
but a ciphertext-only attack would likely have gone along the same lines
as an attack on your cipher. For legal reasons I'm no longer distributing
the essay I co-wrote on the subject ("The Breaking of Cyber Patrol (R) 4")
but it was widely distributed when we posted it a year ago. They were
using 8-bit blocks and you're using 128-bit blocks, but that isn't enough
to make your approach secure.
One fundamental problem is that the initial secret key is used only in
the first block. After that, the new state of the cipher (key, previous
plaintext, previous ciphertext) is completely determined by what happened
in the previous block. So if the previous block is known or controllable,
even partially, it's very easy for the attacker to determine the state of
the cipher, and as soon as they do that they have *all* the rest of the
plaintext from that point on. Even if they only have a 1 in a million
chance of guessing the state on any individual block... after you send a
million blocks, they're pretty likely to have done it. After you send 10
million blocks, it's a virtual certainty they can get the rest of the
transmission. One thing that would be a good idea would be to involve the
intial secret key in *every* mashing operation, not just the first
one... but don't think that that, by itself, would make this cipher
secure. I recommend that you read up on "modes" of block ciphers, among
other things.
--
Matthew Skala
[EMAIL PROTECTED] :CVECAT DELENDA EST
http://www.islandnet.com/~mskala/
------------------------------
From: Darren New <[EMAIL PROTECTED]>
Subject: Re: GPS and cryptography
Date: Wed, 14 Mar 2001 17:52:31 GMT
ObiTwo wrote:
> 1. Sender and receiver must agree on an exact time when both will
> start recording the stream (how to exchange this information lies
> outside Rabin's protocol, as far as I understand). Synchronisation of
> the sender and receiver can be done via GPS as well, which also
> provides time information.
Er, not at terabit/second resolution. That would let you resolve your
location to something like a few milimeters or so.
> Redundant information in the encrypted
> stream could be used to make sure that both parties are in fact using
> the same portion of the stream, even if one of them should start
> recording the stream at a slightly different time than the other.
It would have to, if you're actually talking terabits per second. :-)
--
Darren New / Senior MTS & Free Radical / Invisible Worlds Inc.
San Diego, CA, USA (PST). Cryptokeys on demand.
------------------------------
From: [EMAIL PROTECTED] (Joe H. Acker)
Subject: Re: qrpff-New DVD decryption code
Date: Wed, 14 Mar 2001 19:14:01 +0100
Matthias Bruestle <[EMAIL PROTECTED]> wrote:
> Mahlzeit
>
>
> Douglas A. Gwyn ([EMAIL PROTECTED]) wrote:
> > Matthias Bruestle wrote:
> > > It is theft if the legal system thinks it is theft.
>
> > Theft is a moral/ethical concept, logically prior to legality.
>
> How do you define moral or ethics? If it is what most people do,
> than copying of music is probably not theft.
My God! It is *of course NOT* what most people do! As a German like you,
I hate to bring this example, but do you believe that in the 3rd Reich
in Nazi German what most people did was moral or ethical behavior?
Certainly not! What the majority does or thinks can never be taken as an
argument for or against moral judgements.
> If a minority is
> enough to define morale/ethics, which minority will that be?
Morale/ethics is not defined, it is found and explored. At least that's
what people like I think, who believe that there are things that have an
objective value regardless and independent of subjective preferences.
(But to be fair, there are numerous people who don't believe that. But
even if you don't believe in objective values, you can't just define
what is ethical for you---you are a social being and depend on other
people too. )
> Can I define what morale/ethics is?
Of course you can, but that doesn't make your moral claims right. A
definition is just a definition and is completely immune to being true
or false or wrong or right.
> And if you define theft my moral/ethics, you have also to see the
> usage licenses of musics with moral and ethics in mind, which also
> does not allow them to impose all limitations on us.
Two bad things make no good.
> Is it according your moral/ethics, that copy protections do limit
> the copying of recordings of your mothers wedding or your family
> singing christmas songs? Is it according your moral/ethings, that
> I'm not able to watch films I bought in my holidays? (And now we are
> back to be on-topic. Nearly.)
Look, it's not a good base for laws or ethics, but in this case even
your own moral judgement might help: If you invent something ingenious
that would make you rich (say, an unbreakable cipher or the best
pop-song ever), and if sombody takes it away from you. Wouldn't you
think that this is theft?
I don't know what your profession is, but if you would work as a book
author, journalist, photographer, artist or the like, you certainly
would not claim that it's okay to steal your work and spread it for
free. Freedom of information does not mean that it should be free of
charge, it does mean that everybody should have a chance to get relevant
information. Just like personal freedom does not mean that you may kill
anyone you don't like, and equality does not mean that everybody should
get the same salary (everybody should have the same *chances* to get a
good-payed job).
The problem with the music industry as opposed to the print publishing
industry is that these people are simply too ignorant or too stupid to
realize that the possibilities of the new medias cannot be stopped.
Nobody arrests a student who copies a book he has taken out of a
library, because it is so expensive. Seminars at university aren't
checked by undercover agents for copyright infringement. But apparently,
the music industry thinks law enforcement authorities has no better
things to do than prosecute people who give away a Madonna song to a
friend. They should just realize that their silly copy-protection crap
will never ever work and adjust to the new market conditions. If
somebody has no trouble in finding the music he wants, gets CD box with
good cover art, can get CDs on demand very conveniently and perhaps can
win a candlelight dinner with Madonna or whatever, he will probably be
willing to pay a few bucks for the *service*. That's something the music
industry doesn't seem to get in their heads.
Digital copy protection does not work and just gets on the nerves of
honest buyers, that's why its bad. Not because everybody should steal
the work of artists and other creatives who most often have a hard
enough time to make a living anyway.
Okay, enough OT talk.
Greetings,
Erich
------------------------------
From: [EMAIL PROTECTED] (Daniel)
Subject: Re: Basic Cryptoanalysis
Date: Wed, 14 Mar 2001 18:17:42 GMT
Amethyste, '[EMAIL PROTECTED]', Tom,
Thanks for these links. I was able to download both manuals without
errors this time.
Tom, yes indeed, the Basic Cryptoanalysis is 'BC'-stuff :) but
'easier' to grasp for an intermediate-novice as I am. Last year, I
wrestled trhough the exercises from The Code Book by Simon Singh and
managed to do 7 out of 10 exercises. Not bad, but now it is time to
learn about these systems in more detail. When I fully grasp the
essentials of the Field Ciphers, I can move on to a higher level (and
take some extra math classes as well :)
Best regards,
Daniel
------------------------------
From: [EMAIL PROTECTED] (Daniel)
Subject: Re: Is this book interesting
Date: Wed, 14 Mar 2001 18:35:18 GMT
On Tue, 13 Mar 2001 09:58:17 +0100, "dexMilano"
<[EMAIL PROTECTED]> wrote:
>I'm looking for a light book on Histroy of cryptography.
>What about " The code book" from Simon Singh?
>
>Any other suggestion?
>
>thx
>
>dex
Dex,
I've read the book and also solved most of the exercises given in the
book. If I remember well, the Italian version only has 4 exercises,
while the other versions have 10 exercises. It is a very interesting
book, indeed. See www.simonsingh.com for more info.
Another book I like to read is the CodeBreakers, by David Kahn. This
book has two versions I know of. The classic version, which talks
about crypto up to 1950, and then there's the newer edition, which
adds a new chapter where everything from 1950-1990 is treated. Very
much recommended.
Another very interesting book, which is also easy to read is
"Cryptography decrypted". Lots of visual information on PGP, RSA,
X509, certificates and so on. There is an extra appendix which
contains the "math stuff", as the main part of the book keeps rather
silent on the math. This does not mean that it is useless book, no!
It is a clever book, as it can teach a very difficult subject in a
very easy way!
Try two very interesting links as well :
1) Basic Cryptoanalysis :
http://www.und.nodak.edu/org/crypto/crypto/army.field.manual/
2) Modern analysis for novices
http://fermat.ma.rhbnc.ac.uk/~fauzan/papers/report.pdf
Best regards,
Daniel
------------------------------
** 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
******************************
