Re: question
From: Jack (aegerbearlord_at_rpgbattlezone.com)
Date: 01/30/04
- Next message: Jack: "Re: Multiple key scheme -- Am I gaining anything?"
- Previous message: yama: "Re: aesphm.h?"
- In reply to: Gregory G Rose: "Re: question"
- Next in thread: Michael Brown: "Re: question"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: 30 Jan 2004 06:14:29 -0800
ggr@qualcomm.com (Gregory G Rose) wrote in message news:<bvd278$4v2@qualcomm.com>...
> In article <4019f646$0$28869$afc38c87@news.optusnet.com.au>,
> Necrotica <aclements@optushome.com.au> wrote:
> >> >Exception 1: It has a random seed, that is to say with an 8 character
> >> >password being used the random seeding will be set to either 3, 5, or
> 7,
> >> >with a 9 character password the random seeding will be set to either 2
> 4 6
> >> >or 8.
> >>
> >> I don't understand this at all, not at all.
> >
> >instead of being a standard vignere encryption with the first character in
> >the key and the first character in the plaintext being compared and result
> >recorded it, the first character in the key to be compared is either the 3rd
> >5th or 7th character it then counts thorugh the key for the seed i will use
> >5 for the example
> >
> >key:
> >big&red1
> >
> >the actual key being used is as follows
> >
> >rbeidg1&
> >
> >so the actual key is the 5th character in a row used against a plain text
> >
> >rbeidg1&rbeidg1&
> >hello how are you?
>
> Ahh, gotcha.
>
> >> Ah, finally a clear question. No, this is no
> >> harder to solve than a single Vigenere with a key
> >> as long as the least common multiple of the
> >> individual keys; since it appears that you keep
> >> the same key length for the multiple passes over
> >> the data, it is actually equivalent to the
> >> original Vigenere but with a different (but
> >> related) key, and hence no harder to solve.
> >
> >how it was explained to me was that it wont only be 8 bit if the same
> >character was used throughout the plaintext, but because 8 different
> >characters are used for each 8 consecutive characters in the plaintext would
> >it not be each block of 8 characters in the plaintext is encrypted by 64
> >bits? would it not therefore be that each block of 64 bits has an XOR done
> >on it with 64 bits and therefore a recursive 64 bit encryption for each
> >block of 8?
> >
> >that is to say that for each block of 8 characters in the plaintext
> >
> >64+64+64+64+64+64+64+64
> >
> >each character in the key compared to each character in the plaintext 8
> >times for each block of characters in the plaintext equal to the length of
> >the key which is 8
>
> Well, it was explained to you wrong.
>
> The net effect is this: you add up all the
> characters in the columns:
>
> rbeidg1&rbeidg1&
> qadhcf0%qadhcf0%
> ...
> hello how are you
> =================
> fdsauioye8397876y (or whatever actually results)
>
> Now forget the plaintext for a second... and just
> add up the 8 rows of keys.
>
> rbeidg1&rbeidg1&
> qadhcf0%qadhcf0%
> p`cgbe/$p`cgbe/$
> o...
> n...
> m...
> l...
> k[^b]`*Xk[^b]`*X (where X is actually ascii US, or ctrl-underscore)
>
> Now, whatever these add up to, still repeats every
> 8 characters!
>
> Worse, in a way, is that you just keep adding the
> same characters over and over...
> X + (X-1) + (X-2) ... + (X-7) = X+X+...+X -1-2...-7
> = 8*X - 28 (for each character X in the original password).
>
> Now remember, these are bytes, hence they only
> have 256 possible answers; but 8 is a factor of
> 256! Every 32nd character will in fact end up with
> the same answer... and ascii has patterns in it.
> So, for example, the first character of your
> shuffled password... (note that the shuffling buys
> you nothing at all, BTW) ... is 'r', which is
> equivalent to 'R', and ctrl-R, and meta-R, and
> '2'. They all end up giving you an effective key
> byte of 162*8-28 (mod 256) = 1268 (mod 256)
> = 244
> = meta-N ('N' with the high bit set).
>
> So, now we encrypt with this single, very weird,
> Vigenere key.
>
> The only effect of your machinations was that the
> key, instead of looking like "big&red1", that sort
> of makes sense to a human, now has weird
> non-printable characters in it. But, in return,
> you've actually *reduced* its entropy to 40 bits.
> But that's all irrelevant, since you solve a
> Vigenere by looking at character frequencies. It's
> exactly as weak as the original Vigenere, from
> that point of view.
>
> Hope that was clear.
>
> Greg.
This reminds me (vaguely) of a cipher I saw in a pawn shop. They used
a system similar to that above to show prices, but using a different
word as the key. It was much simpler than the above, as it had no
symbols beyond a few letters of the alphabet. As I recall, the key was
BOOKKEEPER. Perhaps he (the owner) thought a longer word with
repetition would be harder to crack for prospective thieves, not that
there was anything worth taking.
EKKK OBOB, signed, Codebreaker. (I'll give you a hint, use BOOKKEEPER)
- Next message: Jack: "Re: Multiple key scheme -- Am I gaining anything?"
- Previous message: yama: "Re: aesphm.h?"
- In reply to: Gregory G Rose: "Re: question"
- Next in thread: Michael Brown: "Re: question"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
