topbanner_forum
  *

avatar image

Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
  • Thursday April 18, 2024, 8:38 pm
  • Proudly celebrating 15+ years online.
  • Donate now to become a lifetime supporting member of the site and get a non-expiring license key for all of our programs.
  • donate

Author Topic: How do decrypt irssi logs if i have the key? Also question about compiling M.  (Read 10478 times)

pidgey

  • Participant
  • Joined in 2011
  • *
  • default avatar
  • Posts: 2
    • View Profile
    • Donate to Member
I have this problem: i use a satellite receiver based on linux, (Dreambox dm800),  since this box is on 24/7 i installed irssi in it (i found a version already compiled for mips processors, the cpu inside the Dreambox), the problem is that im unable to install blowssi on it (i guess it could be possible to cross-compile it, but it goes behind my present linux skills, very limited tbh), so i cant decode the messages from my beloved chan where we use fish encryption (all works fine if i use mirc + fish script in windows).

The good thing is that Irssi saves the logs with the crypted messages, so, having the key, i suppose it's possible to decode such messages in some way.

Do you know any software that can do such thing? I tried few online tools but it didnt work out, example this: http://www.tools4noobs.com/online_tools/decrypt/ .

BTW... In this chan we use a 98bytes key, and i seen some of this online tools are limited to 56bytes keys.

Also, do you think is possible to crosscompile this  "blowssi - mircryption compat for irssi " https://www.donationcoder.com/forum/index.php?topic=26221.0

and have it to work in a Dreambox? (linux box based on mips processor).


mouser

  • First Author
  • Administrator
  • Joined in 2005
  • *****
  • Posts: 40,900
    • View Profile
    • Mouser's Software Zone on DonationCoder.com
    • Read more about this member.
    • Donate to Member
A point about key size:

My understanding is that all of these implementations of Blowfish, are Blowfish 448, which supports a max key size of 56 bytes.

It may "accept" a 98byte key, but it don't believe it is using more than 56 bytes of it.  though the question is (and the incompatibilities emerge from) which 56 bytes it is using.

I'd love to hear someone with a better understanding of Blowfish448 talk about this, since i've forgotten most of what little i once knew.

pidgey

  • Participant
  • Joined in 2011
  • *
  • default avatar
  • Posts: 2
    • View Profile
    • Donate to Member
i tried to use the first 56bytes or the last 56 but in both cases it didnt decrypt correctly, i have to use the whole 98bytes.

i tried in a random channel using mirc and xchat, both with the fish script.

Maybe it uses the middle part of the key or some other combo.


el_dude

  • Participant
  • Joined in 2011
  • *
  • Posts: 1
    • View Profile
    • Donate to Member
A point about key size:

My understanding is that all of these implementations of Blowfish, are Blowfish 448, which supports a max key size of 56 bytes.

It may "accept" a 98byte key, but it don't believe it is using more than 56 bytes of it.  though the question is (and the incompatibilities emerge from) which 56 bytes it is using.

I'd love to hear someone with a better understanding of Blowfish448 talk about this, since i've forgotten most of what little i once knew.


I'm seeing the same problem as the thread starter, the decryption seems to be wrong for keys larger than 56 characters. I'm trying to figure out how the original FiSH implementation handles this but so far I've only gotten some clues, don't fully understand it :)

In the source http://fish.secure.l...hat.v0.98-source.zip (or the irssi version)

in blowfish.c in the function blowfish_init(), it is first checked whether the key size is larger than 72 ((bf_N + 2) * 4) - where bf_N is defined as 16. If that is the case, the key is truncated and only the first 72 bytes are used for further computations.

Then the following loop seems to do some shifting and XOR'ing for the first 18 bytes in the key (bf_N is 16) using the keysize. This seems to be the only place in the function where the keysize (which can be larger than 56) is used so I guess it happens here.
j = 0;
  if (keybytes > 0) {
    for (i = 0; i < bf_N + 2; ++i) {
      temp.w.byte0 = key[j];
      temp.w.byte1 = key[(j + 1) % keybytes];
      temp.w.byte2 = key[(j + 2) % keybytes];
      temp.w.byte3 = key[(j + 3) % keybytes];
      bf_P[i] ^= temp.word;
      temp.word = 0;
      j = (j + 4) % keybytes;
    }
  }

trying to figure it out, maybe someone here has some ideas..