Re: newbie: please help...just your opinion

From: Scott Contini (contini_at_matmail.com)
Date: 11/10/03 

Date: 9 Nov 2003 19:52:53 -0800

I'm not going to give much of an answer here, since I dont have time to
be working on this, but I will give a few quick thoughts.

"Stephen Cantini" <nospam@nospam> wrote in message news:<3fabd308$1@x-privat.org>...
> Mmmm...the first pass looks quite strong to me.
> Let's say I choose to encrypt a single char (PCH), as you said.
> what kind of infomation can I gain from the ciphertext?
>
> first, the effect of xorfolding: knowing those 8 bits gives 2^24
> possible un-xorfolded values, which are XORed with the first
> pseudo-random
> number. Now, it's sure that there is a relation between ONE of these
> 2^24
> possible hashes (XORed with the first random) and the initial hash
> value
> (i.e. the random seed): knowing both gives you the first key char. But
> how
> can you choose without knowing the seed? Sounds like a chicken and egg
> problem: let's say I choose one of these 2^24 values. Its bits tell me
> only if the bits of rand# and pre-xor hash were different or equal...
>

Yes, it might not work.

> Regarding shuffling, you were right saying it's the place to start
> from.
> I have a different attack in mind: by encrypting a char at a time,
> you know where the shuffling pass has repositioned it (by looking at
> the
> presence of a new char in the ciphertext - one should try to add only
> chars that add different chars to the ciphertext). The problem is that
> since pass2 starts from the END of the ciphertext, the position that
> you
> observe (lets call it "p") is the result of a number of consecutive
> swaps
> from 0 up to plen-p-1 (the character can be selected for swapping
> multiple
> times).
> Now, the higher the number of consecutive swaps have occurred, the
> lesser
> information you can gain about that initial hash value. The initial
> hash
> value also changes every time (since it depends on the value of the
> last
> char - that you know - and its corrisponding key char - unknown).
> However it should be easier, by tracing char movements in the
> ciphertext, to
> determine the hash of the reversed key and the key length too.

Hmmmm... It looks like that if the attacker sends in a plaintext
that is the length of the key, then he is going to learn the entire
modified key since it is nothing but the values of the t that were
computed. Therefore, he can compute the hash that is used in PASS2,
meaning that he can undo the shuffle completely, no?

So imagine an attack where the attacker guesses the length of the
key by trying all possibilities: 1,2,3, etc.... When he guesses the
right one, he can undo the shuffle. Now the attacker has an easier
task of just breaking PASS1. If this is correct, then the shuffle
adds little to the security.

> Having both
> means (especially with a good hash function) having the entire key in
> a
> second. Having the entire key (obviously) destroys immediately pass1
> and
> leads to the plaintext, without fighting with pass1.
>
> The problem with adding MT random numbers also to pass2 is decryption:

I don't think the MT will add any security here (contrary to the thought in
my previous post), at least in terms of the attacks I'm thinking of. So I'll
skip the questions about that.

>
> One last question...do you think multiple iteration of the entire
> algorithm on a plaintext would produce stronger ciphertexts?

It might, I do not know for sure though. It seems it would make it
harder to analyze though.

> Is this a
> general rule (I mean, does ripetitive application of, say, DES with
> the same
> key lead to stronger (or perhaps weaker) encryption)?
>

There is definitely no rule about that. There are examples where the
number of iterations does not improve things at all. A recent example
applied to a hash function is the attacks on SecurID, which are independent
of the number of rounds. There are examples of this in block ciphers as
well - maybe somebody else will comment on that (I think David Wagner
has a few examples).

But although there are examples of where it does not help, there are also
many examples where it does *seems* to help.

Scott

Relevant Pages

  • Re: BitCrypt Explained
    ... Ciphertext is coded in the image by selecting a sequence of pixels ... Attacker identifies stego images by taking histograms. ... Attacker guesses each key character mod 20 by taking 6 histograms ... The attacker hashes the key and compares with the embedded hash. ...
    (sci.crypt)
  • Re: newbie: please help...just your opinion
    ... Let's say I choose to encrypt a single char, ... only if the bits of rand# and pre-xor hash were different or equal... ... presence of a new char in the ciphertext - one should try to add only ... Is there a way to generate random numbers in reverse order? ...
    (sci.crypt)
  • Re: [RFC][PATCH] Make cryptoapi non-optional?
    ... > attacker to get any kind of recognized patterns. ... the random state has zero entropy until the first ... network packet arrives or the pool can be seeded from saved (and well ... SHA revealing more than zero bits of useful entropy per hash. ...
    (Linux-Kernel)
  • Re: Firewall vs. IPS - Differences now (ISS, Intrushield 2.1?)
    ... > You risk running out of memory. ... That's like saying "it's trivial to DoS Aho-Corasic if you know the ... DoS's and improvements via use of the Jenkins hash are most illuminating. ... > replacement policy gives the worst behavior since an attacker can flood ...
    (Focus-IDS)
  • Re: Short Hash codes
    ... >> computation of the hash, a password as well as sequence data known to ... > from Alice to Bob, and you want Bob to be able to verify the message is ... If the attacker were to make ... then the maximum acceptable probability level is quite small. ...
    (sci.crypt)