[15076] in bugtraq
Re: Omnis Weak Encryption - Many products affected
daemon@ATHENA.MIT.EDU (Ben Greenbaum)
Fri May 26 15:10:50 2000
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Message-Id: <Pine.GSO.4.21.0005252055260.21173-100000@mail>
Date: Thu, 25 May 2000 21:18:17 -0700
Reply-To: Ben Greenbaum <bgreenbaum@SECURITYFOCUS.COM>
From: Ben Greenbaum <bgreenbaum@SECURITYFOCUS.COM>
X-To: bugtraq@securityfocus.com
To: BUGTRAQ@SECURITYFOCUS.COM
Eric Stevens said:
> If you break it down by hexadecimal
> pairs, and line up each with a letter of the original password, you get
> e n c r y p t e d
> BE C4 B3 B9 D2 C6 C4 AC BD
> Seems to be a good match for the number of letters. Let's get numeric
> values for each now:
> 101 110 99 114 121 112 116 101 100
> 190 196 179 185 210 198 196 172 189
> If you're reading this with out having tried to decrypt it, you should
> almost at this point have accidentally decrypted it. If you take the
> difference of each of those value pairs, you get
> 89 86 80 71 89 86 80 71 89
> or 89 - (3 * ((charpos - 1) mod 4))
But when I went to test it, that didn't work out. That seems to be more of
a formula to determine the difference between the key of a byte and the
key of the previous byte, meaning that formula would have to be applied
recursively for each byte from that byte's position all the way back to
the last byte position evenly divisible by 4.
After a bit of head scratching, I came up with this, where 'u' is the
unencrypted byte, 'e' is the encrypted byte, and 'p' is the byte's
position in the string mod 4, and assuming the viewpoint of the attacker:
u = e - 89 + (( 3p^2 - 3p ) / 2)
caveat lector:
I don't have any Omnis-generated applications to work with, so all my
testing was done on the plaintext and encrypted strings provided by Eric.
Also, I'm not a crypto genius :) I freely pre-admit I may be wrong.
Ben
