If I understand correctly, the current schematics have both hard-wired
flash for the ARM CPU and also space for an SD card, with the ARM set
up to boot (only) from the hard-wired flash.
a) Is this correct?
b) If so, why do we have the SD card, and is its intended purpose
serious enough to
At Thu, 14 Jan 2016 11:01:38 +0300, Pavel Shatov wrote:
>
> Rob, could you please dump "rho" for all the three curves in
> ecdsa_curves.h? I have a feeling, that "rho" will always be just 1 (one).
Ah. Hadn't noticed that, I'm just calling libtfm setup function:
At Thu, 14 Jan 2016 20:38:24 +0100, Peter Stuge wrote:
>
> Pavel Shatov wrote:
> > Since I'm trying to write ECDSA core, not general-purpose EC math core,
> > I thought, that it would make sense to take advantage of the fact and
> > get rid of that redundant coefficient.
>
> Is there a security
At Tue, 26 Apr 2016 10:49:47 +0200, Fredrik Thulin wrote:
> On Monday, April 25, 2016 05:34:49 PM Paul Selkirk wrote:
> ...
> > 3. RPC client: This runs on a PC on the other end of the USB cable.
> > Currently it's a static library (libhal hal_rpc_* functions), but it
> > needs to be able to
If you don't care about the Alpha's management port command line
interface code or its USB UARTs, you can stop reading now.
I've been testing both Paul's re-port of libcli and Peter's
daughterboards for the USB UARTs.
The good news:
* Paul's re-port seems significantly less quirky than our
At Tue, 19 Jul 2016 10:04:31 +0200, Jakob Schlyter wrote:
>
> Richard Lamb has offered to help out with tamper detection and the plan
> we have come up with is that he will create a small tamper daughterboard
> that connects to the 10-pin tamper GPIO on the alpha board, along with
> some
Thanks, Linus! Will test if I have time before heading to the
airport.
For those following along, two minor changes per discussion with
Fredrik about things he and Linus found confusing while working
through this:
* The environment variable naming the PKCS #11 database has changed:
Was:
We've also put some effort into using constant time algorithms to the
extent possible in the software running on the ARM. As Pavel
suggests, this is not always possible in software (eg, EC point
doubling is a fundamentally different algorithm than EC point addition
for non-equal points), but,
One of the work items that came out of the Berlin workshop is updating
the HSM's internal keystore API to handle (much) larger numbers of
keys, to be able to store additional data beyond just the basic key
data, and so forth. In essence, this means implementing some kind of
filesystem on the
At Tue, 23 Aug 2016 12:07:38 -0400, Rob Austein wrote:
>
> This scheme requires two meta data fields per pair of sectors: a
> serial number and a magic value. General idea is that a sector is
> only valid if it has the right magic value (a constant, 0xdeadbeef
> would do, just can
One of my current projects is revising the internal keystore API used
within the Cryptech HSM software. One aspect of this is figuring out
how to make better use of the keystore flash than we have to date.
I've talked over some of the details of this with Fredrik and Paul,
but wanted to share the
At Tue, 6 Sep 2016 21:56:54 +, Peter Stuge wrote:
>
> ..it sounds like you've just invented a file system.
More like a minimalistic database, which would otherwise be layered on
top of a filesystem.
Well, OK, I skipped over yet another option, which would be SQLite3
directly on raw flash,
At Wed, 07 Sep 2016 00:28:51 +0300, Jacob wrote:
>
> Since storing data in flash cells is not that reliable (strongly
> dependent on age and environment), if you don't rely on a proper
> filesystem to take care of bad data may I suggest to do an ad hoc
> consistency check - maybe by also
Preliminary version of revised keystore API and flash management code
committed and pushed to branch ksng in sw/{libhal,stm32,pkcs11}
repositories. Still needs work before it'll be ready to consider for
merging into the master branch, but the basic mechanism seems to work.
Not yet heavily tested.
> So this means no more sqlite3-dependency anywhere in the code or
> just the p11 part (just curious)?
PKCS #11 is already the only sqlite3 dependency.
Getting rid of the SQLite3 database is a mixed blessing. On the one
hand, having data split between the HSM and the client database means
they
At Mon, 21 Nov 2016 14:04:13 +, Peter Stuge wrote:
>
> Rob Austein wrote:
> > > What would your recommended next step for debugging be?
> >
> > I would not put serious effort into debugging that version, it's far
> > enough behind the current development co
See git.cryptech.is/user/sra/openssl-engine/create-keys.sh.
___
Tech mailing list
Tech@cryptech.is
https://lists.cryptech.is/listinfo/tech
At Fri, 02 Dec 2016 21:12:44 -0500, Rob Austein wrote:
> At Fri, 2 Dec 2016 16:17:23 -0800, =JeffH wrote:
> >
> Some kind of WSGI problem that started after upgrading from
> FreeBSD 9.3 to FreeBSD 10.3 last night, not entirely clear why,
For some reason recompiling Apache, mod_wsg
At Fri, 2 Dec 2016 16:17:23 -0800, =JeffH wrote:
>
> The server is temporarily unable to service your request due to
> maintenance downtime or capacity problems. Please try again later.
Thanks. Some kind of WSGI problem that started after upgrading from
FreeBSD 9.3 to FreeBSD 10.3 last night,
At Tue, 3 Jan 2017 10:09:42 +0100, Yuri Schaeffer wrote:
...
> Moreover, ideally both daemons, but especially the signer run multiple
> threads. With any thread being able to do HSM operations. What I've
> heard from the Berlin workshop (I wasn't there myself) in order to get
> OpenDNSSEC 1.4
At Mon, 2 Jan 2017 21:46:04 +, Peter Stuge wrote:
> Rob Austein wrote:
> > We actually wrote the multiplexer daemon for this before the Berlin
> > workshop, but ended up disabling it because it doesn't run on OSX (it
> > uses PF_UNIX SOCK_SEQPACKET, which OSX doesn't s
At Fri, 23 Dec 2016 22:27:49 +0100, Yuri Schaeffer wrote:
>
> While having 68 keys 'keystore show keys' enumerates the keys except
> after 49 it wraps to 0 again. (But yay for more than 10 objects! which
> was kind of a blocker)
Silly bug in show_keys() (code displays index of inner loop instead
At Mon, 19 Dec 2016 14:26:35 +0100, Fredrik Thulin wrote:
>
> I suspect (hope) the issue is that you are missing this commit in your ksng
> branch. Try merging masster into the branch or cherry-picking this commit:
>
> commit ae8ebceb7c47d38949a92a2f495c990e772d4e51
> Author: Fredrik Thulin
> can I use also other ciphersuites beside the provided, meaning can I
> include my own ciphersuites?
You'd have to write code for you ciphersuites and modify some of our
libraries, but sure, it's all open source, including the software
build and Verilog synthesis scripts.
Old work item which we kept putting off for later. Still not there
(missing a few bits of C and Verilog we'd want to do this), but to get
some of what I've been thinking written down where others can review,
I've posted:
https://wiki.cryptech.is/wiki/SecureChannel
Comments welcome.
Apologies
https://eprint.iacr.org/2017/627.pdf
___
Tech mailing list
Tech@cryptech.is
https://lists.cryptech.is/listinfo/tech
New cryptech-alpha packages available via the usual methods, see
https://wiki.cryptech.is/wiki/BinaryPackages for a refresher.
This update includes some fixes Paul made which should improve
reliability of the RPC UART.
Yeah, I know we should packages for Debian Stretch too now.
Soon(-ish).
On Sat, 23 Sep 2017 20:14:10 +0200, Stephen Farrell wrote:
> On 22/09/17 12:55, Stephen Farrell wrote:
> >
> > As an FYI: I started generating a 20-deep key on a (fairly old)
> > server yesterday during the meeting. It's still working away at> that
> > (using the python code).
>
> And after 25
Sounds like the padding problem Paul fixed months ago:
https://wiki.cryptech.is/changeset/b35b87ea14016760786319a23b87792f1e1041de/sw/stm32#file1
You might want to update the ARM firmware before testing FPGA upload.
___
Tech mailing list
After some API revision and refactoring, I finally have what appear to
be significantly better results for RSA signature time. Data first:
rsa_1024 sigs/sec 31.1885886942 secs/sig 0:00:00.032063 mean 0:00:00.031807
(n 1000, c 1 t0 2018-05-14 00:14:43.666793 t1 2018-05-14 00:15:15.729802)
On Sat, 19 May 2018 01:38:37 -0400, Joachim Strömbergson wrote:
...
> I can build a modified version of the AES core with 16 Sboxes. This
> should cut those 98 seconds to 25 or so. That is fairly easy to do and I
> can start doing that on Tuesday. Ok?
Sure.
> One thing I haven't considered is
Moving key unwrap out from under the keystore lock produces less
surprising behavior: a bitstream with eight ModExp cores and four AES
cores gets best throughput with four parallel clients, which is sane.
So that's one mystery solved.
Timing and profiling tests still running, no new numbers yet.
Adding Peter Gutmann's trick for amortizing the cost of RSA blinding
factors over a long run of signatures was good for approximately 2x
speedup in the RSA code per se. Having blinding on still makes a
difference, but not a dramatic one, so while we might still want to
turn it off occasionally
Summary: 10.3 sig/sec throughput for 2048-bit RSA with eight Modexp
cores and four AES cores (Joachim's most recent version).
AES keyunwrap still dominates, but less of it is thumb
twiddling waiting for the AES core.
There are some relatively minor improvements we might
On Wed, 23 May 2018 01:34:28 -0400, Joachim Strömbergson wrote:
>
> Just to get some clarifications - what was the number of 2048 sigs/s
> before the AES updates?
Don't remember (might be in old email), but I saved the bitstream, so
we can find out what current firmware does with the older
Two wraps per key: one on load, one on first use (precalculation deffered until
then).
--
Sent from a phone, please excuse brevity and typos.
___
Tech mailing list
Tech@cryptech.is
https://lists.cryptech.is/listinfo/tech
On Thu, 24 May 2018 11:14:12 -0400, Russ Housley wrote:
>
> Am I reading this correctly? I am seeing both wrap and unwrap. I
> expected to see an unwrap, private key operation, overwrite the
> memory where the key was stored. This would save a whole bunch of
> AES operations.
The profiling
On Mon, 21 May 2018 13:14:04 -0400, Joachim Strömbergson wrote:
>
> There is now a new AES core in the Cryptech repo: aes_speed.
Thanks! Will profile if it gets that far (first attempt to synthesis
the combined bitstream failed, don't know why yet).
For future reference: a branch of the
Status report to get everybody onto the same page:
* Joachim has done a lot of work on making a faster AES core.
* Integrating that faster AES core into the alpha build does not RSA
signatures noticeably faster. We don't know why. Presumably this
means that the current bottleneck is not
On Fri, 22 Jun 2018 13:09:55 -0400, Michael wrote:
>
> The following packages have unmet dependencies:
>
> cryptech-alpha : Depends: python-serial (>= 3.0) but it is not installable
>
> : Depends: pyhton-crypto but it is not installable
That doesn't make a lot of
On Mon, 25 Jun 2018 13:55:27 -0400, Joachim wrote:
>
> I think Rob, Russ etc need to respond regarding suggestions of
> changing wrapping methods than RFC 3394/RFC 5649 used today.
> I’m just trying to improve the performance of the method used
> today. Quite a lot.
Well, with the understanding
On Fri, 04 May 2018 00:00:10 -0400, Michael wrote:
>
> One curious thing, if I use the "firmware upload" command while in
> cryptech_console, I see the blue LED flash as described in the
> documentation indicating the bootloader is being accessed. Calling
> cryptech_upload from the terminal does
I'll work with Paul on the muxd problem, probably just buffering size mismatch
or similar.
--
Sent from a phone, please excuse brevity and typos.
___
Tech mailing list
Tech@cryptech.is
https://lists.cryptech.is/listinfo/tech
>> I would like this core to directly fetch the KEK from the MKM,
>
>This seems hight desirable to me.
Was always the intention, just nothing we could do about it without the core.
--
Sent from a phone, please excuse brevity and typos.
___
Tech mailing
Failed timing checks again (not necessarily ChaCha this time, just
something). PAR log mailed to Joachim and Pavel for analysis.
___
Tech mailing list
Tech@cryptech.is
https://lists.cryptech.is/listinfo/tech
On Thu, 23 Aug 2018 07:12:15 -0400, Joachim Strömbergson wrote:
>
> I've now implemented the pipeline register in chacha qr. ChaCha now
> meets 100 MHz in the -1 speed grade. I've pushed the changes to the
> master branch.
Build of fmc_clk branch started.
We have Pavel's recommended check for
On April 7, 2018 7:07:07 PM EDT, Linus Nordberg <li...@nordberg.se> wrote:
>Rob Austein <s...@hactrn.net> wrote
>Sat, 07 Apr 2018 18:28:02 -0400:
>
>> The apt URLs are intended for apt-get, not for a browser. Does
>apt-get work with that? Can't check from phone.
&
I'll leave analysis of the crypto impact per se to others who know
more, but given the amount of testing that the TRNG has already had
(some of which we may not be able to repeat because it was done by
third parties who may not volunteer to test a new version), there may
be some value in
On Sun, 30 Sep 2018 07:22:02 -0400, Joachim Strömbergson wrote:
> On 2018-09-29 19:49, Rob Austein wrote:
> > rsa_1024 sigs/sec 15.5909778067 secs/sig 0:00:00.064139 mean 0:00:00.063798
> > (n 1000, c 1 t0 2018-09-29 13:08:21.543547 t1 2018-09-29 13:09:25.683206)
> &
Agree that 8192-bit RSA doesn't seem like a major concern. Paranoids use 4096
now, but I suspect that's mostly biding time for wider deployment of EC and
post-quantum alternatives. 8192 is getting a bit cumbersome, and the steps
beyond that get nasty in fairly short order.
Absence of mature
On Wed, 06 Mar 2019 13:21:35 -0500, Pavel Shatov wrote:
>
> Rob, I have certain questions about the way we store RSA keys. The
> background for those who have not been following is that I've been
> working on a faster ModExp core with full CRT support and integrated
> blinding. Those
On Thu, 07 Mar 2019 09:33:48 -0500, Joachim Strömbergson wrote:
> On 2019-03-04 23:08, Michael Dockter wrote:
> > I was testing some new code in a ST-Cube generated project and now after
> > previously being able to debug the hsm and uart-test .elf files I am not
> > incrementing uwTick and the
On Fri, 08 Mar 2019 19:00:10 -0500, Michael Dockter wrote:
>
> solved. To fully initialize a debug session you must use the gdb
> command "monitor reset halt".
Oh. Yeah, that's a known thing, it's even in Paul's ancient
documentation. Without that, nothing works right.
> At one point the
On Tue, 12 Mar 2019 07:17:02 -0400, Pavel Shatov wrote:
...
> In that light I'm starting to think that my idea to offload the
> computation to STM32 is not that smart after all. Speaking of RISC-V,
> can it get us true constant-time operation?
In theory, constant time C code on a CPU should
https://mailarchive.ietf.org/arch/msg/cfrg/4PmssKzCBsxTmLCieDgqD7Nynwg
___
Tech mailing list
Tech@cryptech.is
https://lists.cryptech.is/listinfo/tech
On Wed, 23 Jan 2019 14:16:22 -0500, Joachim Strömbergson wrote:
>
> This appeared on HN yesterday. A formally verified compiler. It can
> generate code for ARM. Something we could use perhaps?
>
> http://compcert.inria.fr/
I would not object if someone were to contribute code showing how to
use
I defer to Joachim on the CryRev schedule, so if he's OK with this, I
am too.
___
Tech mailing list
Tech@cryptech.is
https://lists.cryptech.is/listinfo/tech
On Tue, 07 Apr 2020 01:41:08 -0400, Joachim Strömbergson wrote:
> On 2020-04-06 23:08, Peter Stuge wrote:
...
> > However, it would also be possible to wire both UART and e.g. SPI up,
> > and only ever use UART to begin with. That works with no software change.
>
> I think this is a very
Thanks for the detailed answer, much appreciated. Unless somebody
else sees a problem, I think Peter has made a pretty good case for
this being both harmless and potentially quite beneficial.
On Tue, 07 Apr 2020 21:42:55 -0400, Peter Stuge wrote:
> Rob Austein wrote:
...
> > Yeah, th
Well, I'm not technically competent to have an opinion on the Amtel
SAMD11, so I'll assume you've done your homework there.
I have no great love for the FTDI chips, and would not mind replacing
them with something better, but I do have two concerns:
1) As you note, somebody would have to write
The Cryptech Project is pleased to announce that version 4 of our
firmware and software package is now available. Like versions 2 and
3, this runs on the Alpha board.
While most of this code became available without much fanfare as we
finished writing it, it's been quite a while since we last
On Wed, 27 May 2020 22:22:20 -0400, Peter Stuge wrote:
...
> On rev03, PCs can only try to use a heuristic with the RPC protocol to
> guess if the board is running/available or not.
>
> This proposed USB interface is self-powered, by VCCO_3V3, so when this
> interface is connected to a PC the USB
On Thu, 28 May 2020 00:12:09 -0400, Peter Stuge wrote:
...
> For one, we can set VID and PID as we please. Since CrypTech is open source
> we can get valid PIDs under the defunct OpenMoko VID at no cost. Or we can
> spend $6000 to get our very own VID. In any case, we can always use the
> reserved
On Fri, 29 May 2020 12:55:39 -0400, Peter Stuge wrote:
...
> In particular those who already use rev03 in production - how do
> applications currently handle the device suddenly becoming
> unresponsive?
RPC hangs or closes, management console hangs or closes. Would have
to check code to see
64 matches
Mail list logo
