Cryptography-Digest Digest #768, Volume #10 Sun, 19 Dec 99 15:13:01 EST
Contents:
Re: compression & encryption (lordcow77)
Re: Casio's Multi Dimensional Space Rotation encryption (David A Molnar)
Re: First Bijective Arithmetic Compression ("Gary")
Re: random numbers straight out of MS BASIC (Scott Nelson)
Re: compression & encryption (John Savard)
Re: Enigma - theoretical question (Jim)
Re: Analogue encryption (Jim)
Re: compression & encryption (Tim Tyler)
Re: First Bijective Arithmetic Compression (Tim Tyler)
Re: Microsoft- PKI/E-comm Director Opening (Tim Tyler)
Re: First Bijective Arithmetic Compression ("Gary")
Re: dictionary attack (Guy Macon)
Re: Casio's Multi Dimensional Space Rotation encryption (CLSV)
Re: Sorry, I was unclear... ("Trevor Jackson, III")
Re: compression & encryption (lordcow77)
Re: Sorry, I was unclear... (Guy Macon)
Re: Analogue encryption ("Trevor Jackson, III")
Re: random numbers straight out of MS BASIC (Guy Macon)
SCOTT's H2COM weakness ("Gary")
D.SCOTT's Compressor Weakness ("Gary")
----------------------------------------------------------------------------
From: lordcow77 <[EMAIL PROTECTED]>
Subject: Re: compression & encryption
Date: Sun, 19 Dec 1999 08:13:27 -0800
In article <[EMAIL PROTECTED]>, Tim Tyler <[EMAIL PROTECTED]> wrote:
> Jerry Coffin <[EMAIL PROTECTED]> wrote:
> [question about compressors addding opatetrened information to the
> file]
> : The alternative view is that the amount of known plaintext
> revealed by
> : this is typically so small that it makes no real difference --
> the
> : attacker has to have broken the encryption quite thoroughly
> before a
> : tiny amount of known plaintext is even marginally useful. A
> known-
> : plaintext attack against a block cipher normally has to have ALL
> the
> : plaintext for a complete block (e.g. 256 bits) known before it's
> of
> : any use at all.
> Curious. The ability to mechanically reject 65535 out of 65536
> keys
> based on decrypting only the first two bytes of a file effectively
> knocks sixteen bits off the key. It pretty much reduces (say) a
> 64-bit
> keyspace to a 48-bit one.
> Decrypting the first two bytes of a file is really not much effort
> compared to decrypting the whole thing, decompressing it and then
> looking
> for the statistics of English text.
> /Perhaps/ your cypher can withstand such a keyspace reduction - if
> it has
> a large enough key in the first place - but why should you
> tolerate such
> nonsense?
> If there is some other attack, or the attacker can determine some
> bits of
> the key by other means, the plaintext provided by the poor
> compression may
> be the final straw.
> Many types of compression leak information while compression is
> in progress - as well as any header they add.
> AFAIK, only things like Huffman and Arithmetic coding typically
> /only/
> leak information at the end of the file. Anything (orthodox) that
> uses a
> sliding window, for example, will leak all the way through the
> compression
> process.
> --
Pray tell, but how would one decrypt just the first two bytes from a
single block encrypted with a block cipher? You can't, and that's why
your "mechanically reject" comment is just wrong.
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: Casio's Multi Dimensional Space Rotation encryption
Date: 19 Dec 1999 16:22:38 GMT
CLSV <[EMAIL PROTECTED]> wrote:
> Has anyone tried to analyze the algorithm?
> (I'm still busy trying to understand it.)
I'm also trying to understand it. At a very vague level, it looks
like "generate random vector and rotation, then rotate message vector
by rotation and OP by that vector." Then they run this in sort of
a chaining mode.
That could be a one-time-pad, but I suspect the difference will come in
the details they give for key generation. Especially that comment about
how XOR is "not safe."
Oh - wait. In the key generation part, they start with a random vector R,
and then rotate it by an angle dependent on some P parameters. So the key
consists of a series of vectors :
r_0 = seed
r_i = a * rotation(r_{i-1}) + c
where rotation() is defined in terms of a parameter set P. The last
section, as far as I can tell, is just a tutorial on how to build rotation
matrices.
They further specify that P and c can be made dependent on the time, but,
like, if you can guess about what time someone sent a message, this
doesn't seem to help much. Plus it's one more thing to agree on in the
key.
So they are using a keystream generator and then combining the output
with the message. Their claim is that it is difficult to recover the
message because the seed, the rotation (), a, and c are unknown.
Thanks,
-David Molnar
------------------------------
From: "Gary" <[EMAIL PROTECTED]>
Subject: Re: First Bijective Arithmetic Compression
Date: Sun, 19 Dec 1999 17:01:13 -0000
As I've replied to David PLEASE, PLEASE, ...PLEASE show me a compression of
any file X that invokes rule 4 when it is decompressed!
------------------------------
From: [EMAIL PROTECTED] (Scott Nelson)
Subject: Re: random numbers straight out of MS BASIC
Reply-To: [EMAIL PROTECTED]
Date: Sun, 19 Dec 1999 17:10:36 GMT
On Sat, 18 Dec 1999 Raddatz Peter <[EMAIL PROTECTED]> wrote:
>I keep reading about how weak and predictable the built in RNG from MS
>is, so I did some testing. The MS RNG has a repeat series of approx.
>256^3 or 16777215.
Mine doesn't. Either there's a flaw in your testing,
in my testing or we have different versions.
Which MS RNG version are you talking about?
>If I create 10 sboxes with 1000 rnd numbers betw. 0 and 256 based on 2,
>rather large, seeds (> 111111111111111 & < 999999999999999)
That's not reasonable as described.
Could you describe that step in a little more detail?
How are you using those large seeds?
Where are the random numbers coming from?
How does the MS RNG fit into all this?
Scott Nelson <[EMAIL PROTECTED]>
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: compression & encryption
Date: Sun, 19 Dec 1999 17:01:42 GMT
On Sat, 18 Dec 1999 14:05:16 -0800, Raddatz Peter <[EMAIL PROTECTED]>
wrote:
>If Zlib leaves a header,
>which I have not seen, that header gets encrypted through RC4.
>Trying to crack the cypherfile you must first reverse the RC4 code and
>then unzip.
Well, the weakness is: if there is a header, this helps trying to
crack the RC4, because you can do a simple brute-force search without
having problems determining, for each trial, if you have found the
right plaintext.
------------------------------
From: amadeus @DELETE_THIS.netcomuk.co.uk (Jim)
Subject: Re: Enigma - theoretical question
Date: Sun, 19 Dec 1999 17:26:57 GMT
Reply-To: Jim
On Sun, 19 Dec 1999 05:26:06 GMT, [EMAIL PROTECTED] (Johnny Bravo) wrote:
>On Sat, 18 Dec 1999 19:21:23 GMT, amadeus @DELETE_THIS.netcomuk.co.uk
>(Jim) wrote:
>
>>>Much more secure than the actual Enigma as the Germans used it, since they
>>>broke all the above rules on a regular basis.
>>
>>Agreed. But the Germans were using it very much more heavily than
>>we are proposing here.
>
> Lack of traffic would definitely be a plus, but for something like
>this why not just use something that wasn't broken more than 40 years
>ago just to avoid the risk.
Quite so.
>RC4 would be a good choice, very simple
>to implement (it would easily fit into a 10 line signature if you
>compacted some of the white space).
But not so much fun!
------------------------------
From: amadeus @DELETE_THIS.netcomuk.co.uk (Jim)
Subject: Re: Analogue encryption
Date: Sun, 19 Dec 1999 17:26:58 GMT
Reply-To: Jim
On Sat, 18 Dec 1999 22:28:43 +0000, Paul Johnstone <[EMAIL PROTECTED]> wrote:
>Fishfone, I like that :)
>
>Were you aware that pressing Ctrl+Alt+F in Netscape takes you to Fishcam?
Don't have Netscape. Fishcam?
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: compression & encryption
Reply-To: [EMAIL PROTECTED]
Date: Sun, 19 Dec 1999 17:21:14 GMT
lordcow77 <[EMAIL PROTECTED]> wrote:
: In article <[EMAIL PROTECTED]>, Tim Tyler <[EMAIL PROTECTED]> wrote:
[Are two bytes in an encrypted compressed header ever important?]
:> Curious. The ability to mechanically reject 65535 out of 65536
:> keys based on decrypting only the first two bytes of a file effectively
:> knocks sixteen bits off the key. [...]
: Pray tell, but how would one decrypt just the first two bytes from a
: single block encrypted with a block cipher? You can't, and that's why
: your "mechanically reject" comment is just wrong.
Simple: pick a key to be tested and decrypt the first block. Depending on
the size of the block, that will /probably/ give you the first two bytes
of the message when decrypted with that key.
Placing mathematical constraints on the keys that can be valid by
using this technique is likely to be more useful to an analyst than
*actually* decrypting and rejecting individual keys.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
Today's subliminal message is
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: First Bijective Arithmetic Compression
Reply-To: [EMAIL PROTECTED]
Date: Sun, 19 Dec 1999 17:26:20 GMT
Gary <[EMAIL PROTECTED]> wrote:
: As I've replied to David PLEASE, PLEASE, ...PLEASE show me a compression of
: any file X that invokes rule 4 when it is decompressed!
You want David to post a hex dump?
I'm not sure what good you think that will do you.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
Smoking cures weight problems eventually.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Microsoft- PKI/E-comm Director Opening
Reply-To: [EMAIL PROTECTED]
Date: Sun, 19 Dec 1999 17:31:46 GMT
[EMAIL PROTECTED] wrote:
: I think this IS microsoft as only they would be silly enough to invest
: in PKI.
All the same, "[EMAIL PROTECTED]" is /not/ a very cute email
address for the director of the project - who seems to have no signature.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
Some things have to be believed to be seen.
------------------------------
From: "Gary" <[EMAIL PROTECTED]>
Subject: Re: First Bijective Arithmetic Compression
Date: Sun, 19 Dec 1999 17:52:13 -0000
Tim Tyler wrote in message ...
>Gary <[EMAIL PROTECTED]> wrote:
>
>: As I've replied to David PLEASE, PLEASE, ...PLEASE show me a compression
of
>: any file X that invokes rule 4 when it is decompressed!
>
>You want David to post a hex dump?
Email me a file which I can compress with David's compressor and when I
decompress it invokes rule 4!
>
>I'm not sure what good you think that will do you.
I think you both realise what good it'll do!
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: dictionary attack
Date: 19 Dec 1999 13:02:02 EST
In article <83is8s$vho$[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Michael
Velten) wrote:
>
>Hi,
>
>can anybody tell me, where i can find a good (german)
>dictionary for a Brute Force-Attack?
While you are at it, I could use a good english brute force
dictionary. I can get a big list of english words, but a
proper brute force dictionary would have non-words such as
"born2run", "xxx", "!@#$%^&*()_+", and "asdfghjkl;'".
This, of course, assumes that the info that I am trying to
guess is something a human choose so as to be easy to
remember.
------------------------------
From: CLSV <[EMAIL PROTECTED]>
Subject: Re: Casio's Multi Dimensional Space Rotation encryption
Date: Sun, 19 Dec 1999 18:16:16 +0000
David A Molnar wrote:
> CLSV <[EMAIL PROTECTED]> wrote:
> > Has anyone tried to analyze the algorithm?
> > (I'm still busy trying to understand it.)
> I'm also trying to understand it. At a very vague level, it looks
> like "generate random vector and rotation, then rotate message vector
> by rotation and OP by that vector." Then they run this in sort of
> a chaining mode.
Hmm, my printer ran out of ink and I don't like to read
this stuff from my screen. The following section however
worries me:
?> Because of this, a person attempting to break the code must reproduce
the
?> method used to generate the rotation operation,
?> identify the function system that governs the generalized
multi-dimensional
?> vector rotation angles, and correctly discover the parameters
?> (keys) that were used.
This sounds too much like security through obscurity.
It is like describing DES but leaving out the S-boxes.
?> For this reason, the program libraries used to encrypt the problem
text
?> are not disclosed here, but we do provide the following information
?> concerning the basics of the algorithm of MDSRTM/MDSR-TDTM.
But these program libraries will be on the Casiopeia.
So why not disclose them.
> [...] So they are using a keystream generator and then combining the output
> with the message. Their claim is that it is difficult to recover the
> message because the seed, the rotation (), a, and c are unknown.
Yes, but will rotation() be a variable or a fixed function?
This is too obscure. I hope they will provide some information
in the future.
Regards,
CLSV
------------------------------
Date: Sun, 19 Dec 1999 13:34:24 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Sorry, I was unclear...
Amos wrote:
> Hi Omar,
>
> Thanks for your feedback.
>
> I am a little worried about cryptographic systems whose workings are unknown.
> The only way I can really rest easy about things like this (no matter if what
> type of software it is), is if the s/code has been subject to extensive public
> debate, or if I wrote it :)
Actually you should be more paranoid about your own code than about others. The
Literature is full of instances in which credible designers overlooked or missed
weaknesses that rendered the results weak.
------------------------------
From: lordcow77 <[EMAIL PROTECTED]>
Subject: Re: compression & encryption
Date: Sun, 19 Dec 1999 10:26:15 -0800
In article <[EMAIL PROTECTED]>, Tim Tyler <[EMAIL PROTECTED]> wrote:
> lordcow77 <[EMAIL PROTECTED]> wrote:
> : Pray tell, but how would one decrypt just the first two bytes
> from a
> : single block encrypted with a block cipher? You can't, and
> that's why
> : your "mechanically reject" comment is just wrong.
> Simple: pick a key to be tested and decrypt the first block.
> Depending on
> the size of the block, that will /probably/ give you the first two
> bytes
> of the message when decrypted with that key.
> Placing mathematical constraints on the keys that can be valid by
> using this technique is likely to be more useful to an analyst than
> *actually* decrypting and rejecting individual keys.
> --
Exactly. You still have to decrypt the entire first block. The time
complexity of breaking the cipher by brute force remains asymtopically
the same. The analyst does have to "*actually*" decrypt the test block
using individual keys.
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Sorry, I was unclear...
Date: 19 Dec 1999 13:36:34 EST
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Amos) wrote:
>My knowledge of cryptographic related terminology and understanding is increasing
>at a dramatic rate. I already had "dictionary attacks" figured, and fortunately
>have always been in the habit of creating passwords like "k!D9f_Ao" and ensuring
>that I change them every 30 days.
>
>Whilst it can be tedious sometimes, I know that one day - vigilance will pay off.
Other tricks:
Turn on numlock, hold down Alt, and type in a number from 0 to 255.
when you release the alt key the ASCII number appears. 255 looks and
acts like a space in DOS filenames - makes it harder for a newbie
to delete your file. The characters between 128 and 255 are best
for passwords
Don't use the same password on different systems.
If possible, use a longer passphrase like
|�mybluedogfrolicswith12wombatsunlessthepenquinexplodes#714-853-1212.
These combine the properties of being hard to guess and easy to
remember. (Don't use any phrase from any book!) Alas, too many systems
limit your passphrase length.
------------------------------
Date: Sun, 19 Dec 1999 13:42:29 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Analogue encryption
Jim wrote:
> On Sat, 18 Dec 1999 22:28:43 +0000, Paul Johnstone <[EMAIL PROTECTED]> wrote:
>
> >Fishfone, I like that :)
> >
> >Were you aware that pressing Ctrl+Alt+F in Netscape takes you to Fishcam?
>
> Don't have Netscape. Fishcam?
There's a fishing simulation game available. You "cast" your line into the water
and sit there watching the static screen waiting for the a fish to strike which
causes the visible bobber to move. I don't think the strikes on the bait are
exponentially distributed.
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: random numbers straight out of MS BASIC
Date: 19 Dec 1999 13:41:24 EST
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Scott Nelson)
wrote:
>Could you describe that step in a little more detail?
>How are you using those large seeds?
>Where are the random numbers coming from?
>How does the MS RNG fit into all this?
One reasonable choice is the QBasic RNG (available free with
any copy of Windows - Start --> Run --> QBASIC). The first thing
that you see is the survival guide, which leads to the docs for
RND and RANDOMIZE. Another reasonable choice is the RNG in
Visual Basic.
------------------------------
From: "Gary" <[EMAIL PROTECTED]>
Subject: SCOTT's H2COM weakness
Date: Sun, 19 Dec 1999 19:33:33 -0000
SCOTT's H2COM weakness
Take two files with the same header (the rest of files can be completely
different).
Use David Scott's H2COM.EXE on both files.
Look at the header output on both compressed files, they are the same!
Therefore an attacker can do the following suppose he can guess that the
header of the plaintext file is "Dear XXXX". He compresses this using
H2COM.EXE and then and uses the compressed header as basis of an attack on
the encryptor.
Thus the compression doesn't hinder conventional analysis of headers.
------------------------------
From: "Gary" <[EMAIL PROTECTED]>
Subject: D.SCOTT's Compressor Weakness
Date: Sun, 19 Dec 1999 19:47:51 -0000
D.SCOTT's Compressor Weakness
Take two files with the same header (the rest of files can be completely
different).
Use David Scott's 1-1 compressor H2COM.EXE on both files.
Look at the header output on both compressed files, they are the same!
Therefore an attacker can do the following suppose he can guess that the
header of the plaintext file is "Dear". He compresses this using
H2COM.EXE and then and uses the compressed header as basis of an attack on
the encryptor.
Thus the compression doesn't hinder conventional analysis of plaintext
headers.
------------------------------
** 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
******************************
