From: jp@jep.pld.ttu.ee (Jyri Poldre)
Date: Tue, 31 May 94 02:58:16 PDT
To: cypherpunks@toad.com
Subject: Estonian RSA chip
Message-ID: <9405310952.AA17082@jep.pld.ttu.ee>
MIME-Version: 1.0
Content-Type: text/plain



I think that i was a bit rushing and did mainly focus on my own problem,
that was this division. 

I will enlighten this more clearly, so that you do not think about me being 
'FSP hard/soft/whateverware stealer'.  
Yes, this chip is basically 'FAST integer calculator' with different levels of microprogamming. I think that user-accessible levels include A*B mod Z , where A,B,Z are 510- local_register_ram_limit nr of bits. The only main difference about commercially available circuits would be relative cheapness- meaning that  modular exponents are optimized in algorithm level, not via HUGE adder, and main force lies in 16 BIT calculations , needed for fast encryption algorithms. (EStimated speed using IDEA will be not less than 2 Mbit/sec, RSA  key exch will be less than 0.4 sec. ), But still it will not contain IDEA or RSA to start with. ( though using primitives like A*B mod Z this is 10~20 lines of code. )  

Now i do explain in a few words, why i do not like the idea of user tinkering with that. Every known cryptosystem using one-way functions contains trapdoor. While there will be no reason in users snooping around with things that run IDEA or DES  just because you might lose the ability to have one-to-one mapping of data, there is nothing wrong in just changing a bit of RSA. Everything would possibly 'LOOK' the same with one guy opening trap^2 door occasionally. That would zero the whole meaning of the chip, what would otherwise work like that:
(just for example i am  using RSA and IDEA. )
CHIP would look like it
-------------------------
RSA,  D1, D2, E1, E2    I
IDEA  K1, K2            I  <---> RAM 
RND generator           I  <---> interface to communication systems
                        I
-------------------------

IN RAM we will keep PUBLIC components and id-s of those we want to keep 
secure chat with. FOR RAM we will have D2,E2 the chips ID will be pair E1,D1
they will be generated inside chip and  !!! Both of them not known to users!!!. when you want to initiate communication you bind 2 chips together and they will exchange public components through trusted channel - meaning you should avoid the write access to that channel- nothing is wrong with read access. It can be achieved rather easyly with 2 chip modules. ( 3 special lines and single sided PCB board- you 'see' the lines and it would rather hard to write into them ) 
after initialisation chips will store their partners Public components and real names in RAM using D2. Now the rest is obvious. After chip A receives talk request from Chip B it looks up public components in RAM and if it matches then uses these do decrypt and get IDEA key from X. If everything is Ok you will get data and the name of CHIP B. Now i cannot guarantee what happens between chip and terminal, but that is not my problem. For this chip-to-chip construct i could give money-back guarantee on some reasonable sums ( dependidng on the length of key change moduli  and while-it-is-safe-to use IDEA or DES or whatever for one session.) 
Now let us look at it from the different viewpoint. Just imagine the possibility of firmware being left to user. I am not even thinking about stupid things like i-will-keep-the-code-secret. This simply won't work. Imagine you being able to reprogam this chip. I know that this would be hard, but it would be NPboring instead of NP-difficult task of factorizing large primes. For me as a constructor it makes no differnce to let or to let not user cahnge microcode technically, but i am still fond of my life and would tell the codes for firmware to publicity at once. Therefore my idea has been from the start open design while in devolopment and no user interaction when in production. 

ARGUE with me. - that is the main idea 


I am anyhow using VHDL firmware devolopment and have my own assembly language for this chip. So far I have decided no interaction in algorithms for user, due to licences it will possibly turn out the other way.


Jyri Poldre from 
Tallinn Technical University
PHONE/fax 372-6-392062 

If it was not for the MIPS
being so good at building CHIPS
the yards would still be open for the lines

remix, 
From Pfloyd, The final Cut