Searching \ for '[PIC]: SHA-1 on PIC16 or PIC18?' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=pic
Search entire site for: 'SHA-1 on PIC16 or PIC18?'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: SHA-1 on PIC16 or PIC18?'
2006\01\29@081203 by Philip Pemberton

face picon face
Hi,
 I'm toying with the idea of implementing SHA-1 on a PIC16F or PIC18F chip.
Just out of curiosity, has anyone done this before?
 It looks like it'll need about 300 bytes of RAM, so that pretty much limits
it to the higher-end chips, but in theory it should be doable...

 What about other crypto/hash algorithms - I'm thinking along the lines of
Skipjack, Blowfish, MD5, etc. Maybe even RSA?

Thanks.
--
Phil.                              | Acorn RiscPC600 SA220 64MB+6GB 100baseT
spam_OUTphilpemTakeThisOuTspamdsl.pipex.com              | Athlon64 3200+ A8VDeluxe R2 512MB+100GB
http://www.philpem.me.uk/          | Panasonic CF-25 Mk.2 Toughbook
... Divers do it better under pressure.

2006\01\29@144109 by Peter van Hoof

face picon face
You should probably check this page:
http://www.brouhaha.com/~eric/crypto/

Peter van Hoof

Philip Pemberton .....philpemKILLspamspam@spam@dsl.pipex.com wrote:

> I'm toying with the idea of implementing SHA-1 on a PIC16F or PIC18F chip.
> Just out of curiosity, has anyone done this before?
> It looks like it'll need about 300 bytes of RAM, so that pretty much limits
> it to the higher-end chips, but in theory it should be doable...

> What about other crypto/hash algorithms - I'm thinking along the lines of
> Skipjack, Blowfish, MD5, etc. Maybe even RSA?

> Thanks.

2006\01\29@172403 by Bob Axtell

face picon face
Philip Pemberton wrote:

>Hi,
>  I'm toying with the idea of implementing SHA-1 on a PIC16F or PIC18F chip.
>Just out of curiosity, has anyone done this before?
>  
>

>  It looks like it'll need about 300 bytes of RAM, so that pretty much limits
>it to the higher-end chips, but in theory it should be doable...
>  
>
The problem is that actually several buffers are needed, as well as
lotsa code space
making it ALMOST impossible on PIC16, unless you use an external SPI
EEROM Memory
arrayed as 32Kx8, and have plenty of buffer space.

>  What about other crypto/hash algorithms - I'm thinking along the lines of
>Skipjack, Blowfish, MD5, etc. Maybe even RSA?
>  
>
Are you sure you need this much security? Couldn't a scrambling
algorithm work OK, as
long as you have good security for the algorithm itself?

--Bob


>Thanks.
>  
>


--
Note: To protect our network,
attachments must be sent to
attachspamKILLspamengineer.cotse.net .
1-520-850-1673 USA/Canada
http://beam.to/azengineer

2006\01\29@173853 by Mark Jeronimus

picon face
You could try an
LFSR<en.wikipedia.org/wiki/Linear_feedback_shift_register>,
it only needs as much extra ram as your key is long plus one bit :P It';s
not cryptographically secure at alll though, but it's very suitable for
Digital Signatures. In fact, CRC is an LFSR with an extra input block and no
streaming output.

The algorithm for a 15-bit two-tap CRC of "x^15+x^1+1" is:
New = (Old<<1) + (Old<0> XOR Old<14>)

Here's a list with valid tap bits. It's hard to come by on the internet, I
had to brute-force them all! (on pentium assembly, still took me hours!)
2 bits: 1, 0
3 bits: 2, 0
4 bits: 3, 0
5 bits: 4, 1
6 bits: 5, 0
7 bits: 6, 0
9 bits: 8, 3
10 bits: 9, 2
11 bits: 10, 1
15 bits: 14, 0
17 bits: 16, 2
18 bits: 17, 6
20 bits: 19, 2
21 bits: 20, 1
22 bits: 21, 0
23 bits: 22, 4
35 bits: 24, 2
38 bits: 27, 2
29 bits: 28, 1
31 bits: 30, 2
(note that some bit lengths have no valid two-tap LFSR's)

Mark

2006\01\29@181917 by Philip Pemberton

face picon face
In message <.....43DD4084.10502KILLspamspam.....cotse.net>
         Bob Axtell <EraseMEengineerspam_OUTspamTakeThisOuTcotse.net> wrote:

> The problem is that actually several buffers are needed, as well as
> lotsa code space
> making it ALMOST impossible on PIC16, unless you use an external SPI
> EEROM Memory
> arrayed as 32Kx8, and have plenty of buffer space.

Yeah, I just ran the numbers again. I came up with a worst-case figure of 512
bytes - there's no way in hell a 16F917 is going to handle *that*. An
18LF6490 could probably do it, but those things are a real pain in the neck
to solder...

The big problem is all the big-name message-digest algorithms need vast gobs
of RAM. All the ones designed for 8-bit architectures and low-memory systems
seem to be trade secrets or completely nonexistent.

> Are you sure you need this much security? Couldn't a scrambling
> algorithm work OK, as
> long as you have good security for the algorithm itself?

What I'm after is a decent hash algorithm or a block cipher that can be
"wired" as a hash.
I'm throwing together a secure ID tag (just for grins). You basically take
the current time (in UNIX timestamp format, but 64 bits long) and an
encryption key, then turn that into a key that's displayed on an LCD. That
key gets entered instead of (or in addition to) a password, and if all goes
well the user gets logged in.

At the moment, I'm toying with the idea of using the TEA algorithm, which is
implementable in about 40 bytes of RAM. Plus I wrote a nice little PIC16
implementation, which I happen to know works fine :)

Why? It seemed like a fun project, and I've got a few calculator LCDs to
repurpose. Hint for folks in the UK: Tesco "Value" brand pocket calculators
(the little black ones that sell for 74p) use a very hackable LCD with an
elastomer connector (Zebra Strip). All you need to rig up is a mounting frame
to compress the elastomer strip.

What is REALLY annoying is that the Mchip datasheet doesn't have any figures
for IntRC startup time. I'm wanting to put the CPU to sleep until the clock
ticks over, then do the generation cycle once a minute. Problem is, if the
osc doesn't start up within a few microseconds, the PIC is going to miss the
low edge of the TMR1 pulse, which will cause TIMER1 to lag by 15us (see the
TIMER1 Module Errata). Gaaah!

Why is there no spec for "Time from interrupt to SLEEP mode exit"?! (Or maybe
there is and I haven't seen it...)

Thanks.
--
Phil.                         | Kitsune: Acorn RiscPC SA220 64M+6G ViewFinder
philpemspamspam_OUTdsl.pipex.com         | Cheetah: Athlon64 3200+ A8VDeluxeV2 512M+100G
http://www.philpem.me.uk/     | Tiger: Toshiba SatPro4600 Celeron700 256M+40G
... Tis but a flesh wound...

2006\01\29@205905 by Jinx

face picon face

> Why is there no spec for "Time from interrupt to SLEEP mode
> exit"?! (Or maybe there is and I haven't seen it...)

Look in Section 3.2.4 (and elsewhere) of the Mid-Range Reference
Manual (2.64MB)

http://ww1.microchip.com/downloads/en/DeviceDoc/33023a.pdf

I'm pretty sure that there is no start-up delay with IntRC

2006\01\30@014335 by Mark Jeronimus

picon face
Jep, as I thought, you wanted a HASH algorithm. Just use a 4-tap LFSR (I
would recommend a Galois, for speed and simplicity), modify it to your
needs. Some valid tap positions are *63*, 3, 2, 0.

I can provide you with some PIC16 code if you can't figure it out yourself.

Mark

On 1/30/06, Jinx <@spam@joecolquittKILLspamspamclear.net.nz> wrote:
{Quote hidden}

> -

2006\01\30@054652 by Jan-Erik Soderholm

face picon face
Jinx wrote :

> I'm pretty sure that there is no start-up delay with IntRC

If there where, there wouldn't any point with the
"Two-Speed startup from sleep" in the nanoWatt devices,
would there ? :-)

The processor first "wakes up" using the intosc and later
(after 1024 Tcy) switches over to the main oscillator. So
you have an additional aprox 250 instructions to "use"
before you're running full speed...

Could be enought to just check something and go
back to sleep even before the main osc is ready.
Could be a major power-saver in some cases.

Regards,
Jan-Erik.



2006\01\30@062255 by Jinx

face picon face

> > I'm pretty sure that there is no start-up delay with IntRC
>
> If there where, there wouldn't any point with the
> "Two-Speed startup from sleep" in the nanoWatt devices,
> would there ? :-)

I see in Table 4-3 of the F88 manual that there is a delay from
SLEEP/POR. "CPU Start-up" is 5-10us with a 1MHz system
clock (presumably that time reduces at 4MHz or 8MHz ?)

That's not quite what the Mid-range manual says about IntRC
start-up in the 16Fs of the time, but the M-RM is a few years
old now, and the F88 has a much more sophisticated clock
block than earlier PICs

2006\01\30@081325 by Bill Freeman

flavicon
face
Philip Pemberton writes:
> Hi,
>   I'm toying with the idea of implementing SHA-1 on a PIC16F or PIC18F chip.
> Just out of curiosity, has anyone done this before?
>   It looks like it'll need about 300 bytes of RAM, so that pretty much limits
> it to the higher-end chips, but in theory it should be doable...

       I have an SHA1 implementation that runs on the PIC16F27A (and
others with enough RAM distributed the right way).  It needs 117 bytes
of RAM 64 bytes of which are in a contiguous block.  This means that
if fits on the mid range devices with 192 bytes of RAM or more.

       It is written in absolute code, but as an include file, so
that it can be spliced into a larger program.  It carefully changes
bank select bits only where necessary, so it would need some work to
make a relocatable version.  As it stands it uses just over half a K
words of program memory.

       RAM layout is dicey for relocatable if you want to take
advantage of the fact that you can re-use some of the 117 of RAM for
other purposes between bytes of input.  (Obviously you can reuse all
of the RAM between sums.)

       I'd be willing to make it available free for non-commercial
use, and reasonably license it for commercial use.  Do folks have
license suggestions?

                                                       Bill

2006\01\31@092059 by Bill Freeman
flavicon
face
Bill Freeman writes:
...

>        I have an SHA1 implementation that runs on the PIC16F27A (and

       Sorry.  That should be PIC16F627A.  Not that the code is fussy
if RAM is adequate.

                                                       Bill

More... (looser matching)
- Last day of these posts
- In 2006 , 2007 only
- Today
- New search...