Eastern Daylight Time | 20 Jun 02:23 2016

Ben Nanonote - Emacs and Alternate OSes

Hey guys,

I know this isn't a high-volume mailing list or anything, so this
topic isn't liable to generate an enormous amount of discussion, but I
figure if I'm likely to get the chance to talk to anyone else actively
using the nanonote it's probably going to be here or on the IRC.

I'm relatively new to using the Nanonote, and though I'm not really a
hardware guy (that's threatening to change with something like this
device) I see a lot of potential in the device for solid use.  I know
emacs has been ported to the nanonote, and see that the qi hardware
wiki page on software included has it listed, but even though I
flashed my nanonote using the wiki's instructions it's not on there.
Since a lot of what I do with computers is through emacs (I like the
unified interface with text it provides, and it's a cool lisp machine
on its own) I was wondering how it would be easiest to install on the
nanonote.

Another thing I'm holding under consideration is running Debian or
Gentoo (the MIPS ports of either) on my nanonote.  Anyone have any
experience with either?  Thoughts?

Best Wishes,
EDT

_______________________________________________
Qi Hardware Discussion List
Mail to list (members only): discussion <at> lists.en.qi-hardware.com
Subscribe or Unsubscribe: http://lists.en.qi-hardware.com/mailman/listinfo/discussion
Paul Boddie | 9 Jun 18:44 2016
Picon

Not a New NanoNote: ELLO 2M

Hello,

I thought I'd post this and get flamed anyway. Someone brought the following 
Crowd Supply project to my attention very recently:

https://www.crowdsupply.com/knivd/ello-2m

The NanoNote connection is somewhat tenuous but still interesting: it's an 
open hardware design, has a keyboard and screen (and thus isn't yet another 
"headless" single-board computer), and it uses a microcontroller in the MIPS-
based PIC32 family as its CPU. It isn't at the same level of sophistication as 
the Ben, but I guess it shows off some interesting common aspects of how such 
products are designed and made.

The whole PIC32 phenomenon is interesting to observe. Although we're talking 
about things with relatively little RAM - 128K or 512K in this case - they 
tend to have more RAM than the average ARM microcontroller (and obviously much 
more than the ubiquitous AVR stuff turned out by Arduino, Adafruit and so on). 
That's been enough to let people run Unix variants like RetroBSD on PIC32 
boards:

http://retrobsd.org/wiki/doku.php

Another Crowd Supply campaign that was also pointed out is this one:

https://www.crowdsupply.com/soniktech/zamek

That one seems to want to play in the Anelok space. ;-)

Paul
(Continue reading)

Werner Almesberger | 1 Jun 05:44 2016
Picon
Gravatar

Anelok: case update - arrival of the buttons

I finally got around to adding the buttons to the case design.
This is the new shape:
http://downloads.qi-hardware.com/people/werner/anelok/tmp/case-20160531.png

With annotations:
http://downloads.qi-hardware.com/people/werner/anelok/tmp/case-ann-20160531.png

I also had to grow the case a little bit more. The length is now 55 mm,
up from 54 mm. I hope the buttons will be large enough to feel "good".
They are 8 x 8 mm, a bit smaller than the roughly 9.6 x 10 mm of the
buttons of the modified CR2032 device I use for experiments these days.

The buttons are also slightly vertically off-center with respect to
the display (about 10% of the display height), but that's probably
unnoticeable.

- Werner

_______________________________________________
Qi Hardware Discussion List
Mail to list (members only): discussion <at> lists.en.qi-hardware.com
Subscribe or Unsubscribe: http://lists.en.qi-hardware.com/mailman/listinfo/discussion
Werner Almesberger | 20 May 19:44 2016
Picon
Gravatar

Anelok: the crypto reform (4/4), implementation and future

Middleware
----------

The middleware related to handling account databases covers three
areas:

- the actual cryptographic primitives,
- the code that reads or writes account records, and
- base32 encoding/decoding for when a human-readable representation
  of a key is needed.

There are two implementations of Anelok's cryptography, one in the
firmware and another for host tools. The firmware can only read the
account database so far, but not edit it. The host tools can read
and write.

The bits in the firmware:

- cryptographic primitives:

  TweetNaCl:
  https://gitlab.com/anelok/anelok/blob/master/crypter/tweetnacl.h
  https://gitlab.com/anelok/anelok/blob/master/crypter/tweetnacl.c
  from
  https://tweetnacl.cr.yp.to/
  included via
  https://gitlab.com/anelok/anelok/blob/master/fw/db/crypto/tweetnacl.c

  uNaCl (optimized elliptic curve multiplication):
  https://gitlab.com/anelok/anelok/tree/master/fw/db/crypto/unacl
(Continue reading)

Werner Almesberger | 20 May 18:19 2016
Picon
Gravatar

Anelok: the crypto reform (3/4), what all this looks like

Let's assume we have the following accounts:

Name:   Mail
URL:    foomail.com
Login:  me
PW:     Fohd3ien

Name:   SocNet
URL:    sidetome.com
Login:  goatee81
PW:     asdf

Someone who has access to the encrypted account database but doesn't
know the right keys would be able to see this:

% ./crypter.py default.bin
Length: 174 bytes
  PKw: HWUZ-CSHI-M4TV.ZTGX-7NCR-LMSR.QFCC-7N7A-BYN3.XSIH-DOQY-TFJ4.MN3A
  Nonce: N6TD-ZM6F-ASPY.G3I8-BFN8-XPII.JHH6-XMVG-JZLS.IIC
  Readers: 1
    PKr: HWUZ-CSHI-M4TV.ZTGX-7NCR-LMSR.QFCC-7N7A-BYN3.XSIH-DOQY-TFJ4.MN3A
    EKr: W9E7-A7LF-E6BZ.AQ3L-8VVQ-MRTA.G4SF-3JYW-ZXYE.LO3R-ARFT-DSWU.NFTB
  Payload: 53 bytes
    28 4A 9F 37 F0 2F 25 8B 59 25 DE 9A 96 D6 D3 3B  (J.7./%.Y%.....;
    DC 1E 01 EE 91 DD 97 AE 77 94 88 5B 43 3E FC B3  ........w..[C>..
    4E BA 39 27 A0 3E 11 7B 4F BF 88 00 9E 3A E4 4E  N.9'.>.{O....:.N
    1B 50 01 51 61                                   .P.Qa
Length: 179 bytes
  PKw: HWUZ-CSHI-M4TV.ZTGX-7NCR-LMSR.QFCC-7N7A-BYN3.XSIH-DOQY-TFJ4.MN3A
  Nonce: HFUI-AUGI-QWVJ.AAAU-DGQF-FKVU.HD9S-BXZ9-WSQN.OGA
(Continue reading)

Werner Almesberger | 20 May 17:15 2016
Picon
Gravatar

Anelok: the crypto reform (2/4), format and algorithm

The records in the account database have the following format:
http://downloads.qi-hardware.com/people/werner/anelok/tmp/crypto-format-20160518.pdf
https://gitlab.com/anelok/anelok/blob/master/doc/crypto/format.fig

I also have a description in text form, along with the algorithm:
https://gitlab.com/anelok/anelok/blob/master/crypter/README

The main steps of encryption are:

1) We generate a nonce (N) and the random key (RK) used to encrypt the
   record content.

   N has to be unique per record encryption but doesn't have to be
   difficult to guess, while RK must be unguessable (for an outside
   party) and it must be unique at least per group of records with
   the same readership. In practice, this means that RK should be
   unique per record, but an existing RK could be reused if changing
   a record, as long as the readership remains the same.

2) For each reader, we perform the key agreement using Curve25519,
   obtaining a secret (ShK) shared between reader and write.

   This is the "beforenm" part of https://nacl.cr.yp.to/box.html

3) We encrypt RK with key ShK using crypto_stream_xsalsa20, yielding
   the encrypted key EKr. While there is only one RK per record,
   there is a different EKr for each reader allowed to decrypt the
   record.

   https://nacl.cr.yp.to/stream.html
(Continue reading)

Werner Almesberger | 20 May 15:48 2016
Picon
Gravatar

Anelok: the crypto reform (1/4), overview

So far, the account database format only supported one reader per
record and the tools for creating the database used only a single
key pair, which kinda defeats the purpose of public-key cryptography.

After some hands-on experience with NaCl
https://nacl.cr.yp.to/index.html
and studying Dan Bernstein's paper on how it all works under the hood
http://cr.yp.to/highspeed/naclcrypto-20090310.pdf
I felt confident to take the next step and to implement multi-reader
encryption.

This required a change of the database format and the introduction of
encrypted per-record keys. You may remember this diagram
http://downloads.qi-hardware.com/people/werner/anelok/tmp/crypto-accreg-20150420.pdf
from these threads:
http://lists.en.qi-hardware.com/pipermail/discussion/2015-April/010850.html
http://lists.en.qi-hardware.com/pipermail/discussion/2015-April/010851.html
http://lists.en.qi-hardware.com/pipermail/discussion/2015-April/010852.html
http://lists.en.qi-hardware.com/pipermail/discussion/2015-April/010854.html

The updated version is quite similar:
http://downloads.qi-hardware.com/people/werner/anelok/tmp/crypto-accreg-20160520.pdf
https://gitlab.com/anelok/anelok/blob/master/doc/crypto/accrec.fig

The main changes are that I removed the key derivation function (KDF),
the initialization vector (IV) is now a nonce, and involving hashes
in the generation of random numbers is less encouraged than before.

The KDF simply wasn't necessary: the Curve25519 key agreement produces
a 32 byte key, which is exactly the size of the secret key for the
(Continue reading)

Paul Boddie | 17 May 20:29 2016
Picon

Anelok: The Yubico opportunity

Sorry to use the "Anelok:" prefix, Werner, but I don't want people complaining 
about the topic after opening the message. ;-)

Anyway, this story has been "trending" recently: Yubico has apparently gone 
completely closed on their latest product, as opposed to somewhat closed, 
meaning that the whole transparency argument has erupted around their 
token/key/credentials-management products...

"Yubico: Secure hardware vs. open source"

http://lwn.net/Articles/687676/

Indeed, the blog post that initiated the fuss is perhaps something worth 
mining for good discussion points...

https://www.yubico.com/2016/05/secure-hardware-vs-open-source/

It's interesting to read that they ditched the Java Card stuff in their latest 
product. I saw an interesting talk about writing applets for that platform and 
it was a rather informative and entertaining glimpse behind the curtain into a 
somewhat bizarre world:

https://www.youtube.com/watch?v=31D94QOo2gY

Maybe there's an opportunity to be had here with Anelok. Get yourself a Let's 
Encrypt certificate for anelok.com and maybe people can be sent in that 
direction for more details. ;-)

Paul

(Continue reading)

Wolfram Sang | 10 May 16:09 2016
Picon

KS7010 driver goes staging

Hi,

I wanted to let you know that I just sent a patch series to put the
KS7010 driver for the Spectec SDW-823 card to upstream staging. It
included also a round of cleanups and bugfixes. See here:

http://thread.gmane.org/gmane.linux.kernel.renesas-soc/3554

Since the base of the series comes from the Nanonote project, I thought
maybe some interested persons might be still around here? In any case,
thanks to all involved in this driver so far. Much appreciated!

Regards,

   Wolfram

_______________________________________________
Qi Hardware Discussion List
Mail to list (members only): discussion <at> lists.en.qi-hardware.com
Subscribe or Unsubscribe: http://lists.en.qi-hardware.com/mailman/listinfo/discussion
Werner Almesberger | 12 Apr 14:42 2016
Picon
Gravatar

Anelok: battery contacts revisited

In http://lists.en.qi-hardware.com/pipermail/discussion/2016-March/011019.html
I calculated/guessed the length of the contacts (i.e., the distance
between rear and battery) as 2.04 mm for Keystone 5225 and 2.54 mm
for Keystone 5203.

With a nominal battery size of 43.9 mm (+/- 0.6 mm) this yields a
total length for battery with contacts of 48.48 mm.

I wrote "calculated/guessed" since the drawings of the contacts
don't indicate the position relative to the battery (or relative
to each other).

But I now found this information on in the catalog:
http://www.keyelco.com/userAssets/file/Keystone-CatalogM65.pdf
Catalog page 37, PDF page 43.

They suggest a spacing of 49.5 mm, about 1 mm + tolerance more than
what I had. If we assume a tolerance of 2 * 0.1 mm, the case will
thus have to grow to a total width of at least 53.7 mm.

Since I'll have to stretch it to at least 54.0 mm to accommodate
the mechanical buttons anyway, this fits quite nicely.

- Werner

_______________________________________________
Qi Hardware Discussion List
Mail to list (members only): discussion <at> lists.en.qi-hardware.com
Subscribe or Unsubscribe: http://lists.en.qi-hardware.com/mailman/listinfo/discussion
Werner Almesberger | 28 Mar 00:47 2016
Picon
Gravatar

Anelok: keeping the time during battery swaps (2/2)

The timekeeping gets an unplanned second part, for a fifth variant.
Fifth time is lucky, right ? :-)

http://downloads.qi-hardware.com/people/werner/anelok/tmp/time-backup-20160328.pdf

All the circuits presented so far have the issue that a voltage
above Vcc is present at the MCU's GPIO(s) when Vc1 > Vcc. This
is outside the chip's specification and may or may not cause
trouble.

Joerg suggested another variant, on page 5: the diode is now at
the MCU and thus clamps Vadc to Vcc. A standard diode with Vf
around 0.3 V at 1 uA (e.g., Panasonic DA2J10100L) should work
nicely for this.

One issue with the circuit is that the leakage current of the
ADC pin flows through the 3.3 MOhm resistor, which may cause a
voltage offset that is as large as the whole measurement range.
The magnitude of the leakage should depend largely on the chip
temperature.

Joerg suggested an algorithm that may help there, too. To take
a sample of the unknown Vc1, we would do something like this:

static void pulse(float duty)
{
	output(1);
	sleep(INTERVAL * duty);
	output(0);
	sleep(INTERVAL * (1 - duty));
(Continue reading)


Gmane