Crypto patch

[jackkleeman]

Hi guys, could you push the crypto patch to a branch? My device is totally useless without it

[iceman1001]

there one big problem, the crypto1 patch is too big for the 32kb we can play with. The compiled firmware image doesn't fit and renders your device totally useless..

[jackkleeman]

Can you put it as a branch anyway? I would prefer to remove lots of other features as I only need classic 4k.

[andrei-cb]

Is it possible to replace the ATxmega32A4U with a ATxmega128A4U and stay compatible with the original firmware (and this one as well)?

The only differences are the program memory, eeprom size and ram kbytes.

[iceman1001]

good question. Don't know if the GPIO pins are the same... regrettfully I don't know what difference has been done to the pin mappings.

[andrei-cb]

It looks like all xmega A4U microcontrollers have the same pinout. ( http://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-8387-8-and16-bit-AVR-Microcontroller-XMEGA-A4U_Datasheet.pdf )

I'm going to give ATxmega128A4U a try when my lab401 order arrives and see how that works out.

[iceman1001]

A missunderstanding, the question is which GPIO pins has been connected on the PCB with the MCU. Not if the GPIO pins are the same on the two MCU.

[WolfgangMau]

at least it is not possible to run the firmware of the reve-rebooted on a revg ( without refactoring ) -I‘ve tested that

…

Am 17.02.2018 um 21:11 schrieb Iceman ***@***.***>: A missunderstanding, the question is which GPIO pins has been connected on the PCB with the MCU. Not if the GPIO pins are the same on the two MCU. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[icsom]

additional note: of course I changed the mcu-type in the Makefile ;-)

…

Am 17.02.2018 um 21:4makefile0 schrieb Wolfgang Mau ***@***.***>: at least it is not possible to run the firmware of the reve-rebooted on a revg ( without refactoring ) -I‘ve tested that > Am 17.02.2018 um 21:11 schrieb Iceman ***@***.***>: > > A missunderstanding, the question is which GPIO pins has been connected on the PCB with the MCU. Not if the GPIO pins are the same on the two MCU. > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub, or mute the thread. > — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[iceman1001]

Got hold of @Iskuri He has optimized a crypto1 implementation before, so lets keep our fingers crossed!

[bogiton]

Is there any progress on that? Should we try to add the existing (big) patch in the next release?

[iceman1001]

nay, the big patch takes all memory available...
you can always make a patched firmware version with it, but I still have faith in @Iskuri

[bogiton]

hehe I put my faith in @Iskuri as well.
I should just be patient then for the new release! :P

[Iskuri]

Don't worry guys I am still on it, unfortunately life has gotten in the way a bit but I have more free time to look at it this week and will be doing so.

[iceman1001]

not the least worried, I am just more eager to see it :)

[Iskuri]

Hey guys, I've made some progress on this one, I've just got a few annoying bugs to iron out with it and then I'll do some cleanup and make a pull request. I've basically integrated a lot of my code that was optimised in AVR Asm into it and changed the core codebase to better work with this. This means that the Crypto1Byte and Crypto1Nibble calls have been updated to call an asm function called Crypto1Bit which does the filter and PRNG succession functionality that's usually performed by Crypto1FilterOutput and Crypto1LFSR. I've only changed things in Crypto1.c so far and created a new file for the asm functions called Crypto1_asm.S. I've not run any speed checks yet as I need to iron out the bugs but after I have I will work a bit more on any other optimisations. I'm also planning on hardcoding the PRNG'ed nonces in the parts where the nonce is already hardcoded as this will save a hell of a lot of time as well.

[iceman1001]

Sounds promising @Iskuri

[iceman1001]

I merged @Iskuri 's PR. It compiles and runs.
@jackkleeman you can test to see if your issues is solved with it?

[jackkleeman]

Sure although my big problem is the broken code for the mifare classic 4k.

[iceman1001]

@jackkleeman one step at the time. First test this one.

[jackkleeman]

This solved my speed of crypto problem