If we manage to get our fingers at a RAM dump I doubt we will have to do anything further to crack the key. Disassembling the bootloader should reveal the key/iv pretty fast. Even if we would be able to guess the first 16 bytes of plaintext, I doubt a bruteforce attack would make any sense, 128 bits of key AND iv space are simply too much, more than 10^77 possibilities. Our main hope are the games. Is there really no one with a 3g nano or classic out there?
Jeremy Prater schrieb: > Almost but not quite, a repetitive block of plain-text is encoded with the > previous cipher-text as the IV (initialization vector) which sets the > 'state' of the cipher. Then it is encoded with the same key for each block. > Quote from RFC 3602.. http://www.faqs.org/rfcs/rfc3602.html > > The IV is XOR'd with the first plaintext block before it is > encrypted. Then for successive blocks, the previous ciphertext block > is XOR'd with the current plaintext, before it is encrypted. > > About memory dumps, only the first block (16-bytes) is required to recover > the key. Some aes implementations have the key and the iv. Some references > always set iv as 0x0000000000000000 but it has the ability to be set as any > 128-bit value. Even if we did have the plain-text we would need the key and > the iv (if its used). > > -----Original Message----- > From: MsTiFtS [mailto:[EMAIL PROTECTED] > Sent: Wednesday, October 03, 2007 8:05 AM > To: Hardware and developpement mailing list. > Subject: Re: [Linux4nano-dev] Concerning a block cipher. > > Jeremy Prater schrieb: > >> The 240byte position split in the various versions in the aupd verify >> the block size is 16byte (128-bit). It is odd that the aupd and osos >> filesizes are multiples of 2048 also, I thought it could be just a >> coincidence in osos, but both files is odd. To use decrypting >> functions in winhex goto edit | convert (ctrl + r) and it brings a box >> up, also hackman hexeditor can do decryption. I use them both for >> testing stuff. I don't really know where to go from here, aes-cbc is >> difficult to get the plain-text from the cipher-text, I was looking at >> 1g nano firmware to see about strings and stuff, but I doubt any of >> that data made it into the 2g firmware. Later -- Jeremy >> >> > I guess these files are just padded to fill the 2K blocksize of the flash. > Well, there are definitely a lot of strings and stuff we know must be in > there, but we don't know where they are. I would have also guessed that > there would be at least some zero padding, but I couldn't find any > repetitive ciphertext blocks, no matter how hard I search. If I > understood the workings of a CBC cipher correctly, repetitive blocks of > plaintext must yield repetitive blocks of ciphertext, right? > What ways are there to crack the key if you know plaintext AND > ciphertext? Does that need a brute force attack? > > Thanks for your good and hard work ;) > >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Linux4nano-dev mailing list >> [email protected] >> https://mail.gna.org/listinfo/linux4nano-dev >> http://www.linux4nano.org >> > > > > > > _______________________________________________ > Linux4nano-dev mailing list > [email protected] > https://mail.gna.org/listinfo/linux4nano-dev > http://www.linux4nano.org > > _______________________________________________ Linux4nano-dev mailing list [email protected] https://mail.gna.org/listinfo/linux4nano-dev http://www.linux4nano.org
