<div dir="auto">Who creates session key? GnuPG or hw token?<div dir="auto"><br></div><div dir="auto">Does yubikey built in pseudorandom generator takes any part in generating session key?</div><div dir="auto"><br></div><div dir="auto">FST-01 has a script to induce some random bits, why is that needed? FST-01 does not have neug builtin if i am correct.</div><div dir="auto"><br></div><div dir="auto"><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Oct 19, 2017 11:43 AM, "Srinivas V" <<a href="mailto:vsrinu26f@gmail.com">vsrinu26f@gmail.com</a>> wrote:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto">I see this as a feature as i can put my own vid pid to make sure any malicious software is not targeting usb devices based on a particular vid pid.<div dir="auto"><br></div><div dir="auto">Again many talk about performance you can use multiple tokens with same keys simultaneously on different machines.</div><div dir="auto">(I dont know if multiple tokens with same keys on same machine will be supported for performance for high volume scenarios)</div><div dir="auto"><br></div><div dir="auto">Gnuk design goal is not about performance. We should not distract here.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Oct 18, 2017 7:02 AM,  <<a href="mailto:gnuk-users-request@lists.alioth.debian.org" target="_blank">gnuk-users-request@lists.<wbr>alioth.debian.org</a>> wrote:<br type="attribution"><blockquote class="m_8952601287289977991quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Send gnuk-users mailing list submissions to<br>
        <a href="mailto:gnuk-users@lists.alioth.debian.org" target="_blank">gnuk-users@lists.alioth.debian<wbr>.org</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
        <a href="https://lists.alioth.debian.org/mailman/listinfo/gnuk-users" rel="noreferrer" target="_blank">https://lists.alioth.debian.or<wbr>g/mailman/listinfo/gnuk-users</a><br>
or, via email, send a message with subject or body 'help' to<br>
        <a href="mailto:gnuk-users-request@lists.alioth.debian.org" target="_blank">gnuk-users-request@lists.aliot<wbr>h.debian.org</a><br>
<br>
You can reach the person managing the list at<br>
        <a href="mailto:gnuk-users-owner@lists.alioth.debian.org" target="_blank">gnuk-users-owner@lists.alioth.<wbr>debian.org</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of gnuk-users digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
   1. Re: Gnuk 1.2.6 / NeuG 1.0.6 / Chopstx 1.5 / Fraucheky     0.5<br>
      (Daniel Kahn Gillmor)<br>
   2. Re: [PATCH 0/7] Gnuk: add support for Cortex M4 MCU (NIIBE Yutaka)<br>
<br>
<br>
------------------------------<wbr>------------------------------<wbr>----------<br>
<br>
Message: 1<br>
Date: Tue, 17 Oct 2017 23:09:54 -0400<br>
From: Daniel Kahn Gillmor <<a href="mailto:dkg@fifthhorseman.net" target="_blank">dkg@fifthhorseman.net</a>><br>
To: NIIBE Yutaka <<a href="mailto:gniibe@fsij.org" target="_blank">gniibe@fsij.org</a>>, Vagrant Cascadian<br>
        <<a href="mailto:vagrant@debian.org" target="_blank">vagrant@debian.org</a>>, Gnuk and NeuG<br>
        <<a href="mailto:gnuk-users@lists.alioth.debian.org" target="_blank">gnuk-users@lists.alioth.debia<wbr>n.org</a>><br>
Subject: Re: [Gnuk-users] Gnuk 1.2.6 / NeuG 1.0.6 / Chopstx 1.5 /<br>
        Fraucheky       0.5<br>
Message-ID: <<a href="mailto:87h8uxtam5.fsf@fifthhorseman.net" target="_blank">87h8uxtam5.fsf@fifthhorseman.<wbr>net</a>><br>
Content-Type: text/plain; charset="us-ascii"<br>
<br>
On Mon 2017-10-16 10:56:58 +0900, NIIBE Yutaka wrote:<br>
> The agreement is available (it's not FSIJ specific) from USB.org.<br>
<br>
oof, what a complicated and annoying arrangement :/<br>
<br>
> Is it acceptable for users, my preparing of some tool which generates<br>
> final binary from binary template?  I mean, we will distribute binary<br>
> without VID:PID, and it will be an end user who will put the VID:PID<br>
> at the field.<br>
<br>
This seems like a sensible way around the problem to me, but i'm not a<br>
lawyer :)<br>
<br>
I note that debian already distributes that VID and PID though, right?<br>
Just not in the firmware explicitly:<br>
<br>
0 dkg@alice:~$ grep -A1 Gnuk /lib/udev/rules.d/60-scdaemon.<wbr>rules<br>
## Gnuk Token<br>
SUBSYSTEM=="usb", ATTR{idVendor}=="234b", ATTR{idProduct}=="0000", ENV{ID_SMARTCARD_READER}="1", ENV{ID_SMARTCARD_READER_DRIVER<wbr>}="gnupg"<br>
0 dkg@alice:~$<br>
<br>
As long as you're not somehow enjoined from shipping this set of four<br>
octets in *any* combination as a result of your agreement with USB-IF<br>
(which seems like it would cause trouble for your work on scdaemon) it<br>
seems fine to me to have a firmware image that ships with a slot<br>
designed to hold the VID:PID, and to have that slot filled in by an<br>
argument to the firmware installer tool.<br>
<br>
That would also presumably help us verify the reproducibility of the<br>
Gnuk firmware as well (because we wouldn't see a difference based on<br>
different VID:PID options if the firmware we're shipping has a standard<br>
(fixed) placeholder for those values).<br>
<br>
thanks for helping explain this complicated situation!<br>
<br>
        --dkg<br>
-------------- next part --------------<br>
A non-text attachment was scrubbed...<br>
Name: signature.asc<br>
Type: application/pgp-signature<br>
Size: 832 bytes<br>
Desc: not available<br>
URL: <<a href="http://lists.alioth.debian.org/pipermail/gnuk-users/attachments/20171017/0550d15a/attachment-0001.sig" rel="noreferrer" target="_blank">http://lists.alioth.debian.or<wbr>g/pipermail/gnuk-users/attachm<wbr>ents/20171017/0550d15a/attachm<wbr>ent-0001.sig</a>><br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Wed, 18 Oct 2017 15:47:10 +0900<br>
From: NIIBE Yutaka <<a href="mailto:gniibe@fsij.org" target="_blank">gniibe@fsij.org</a>><br>
To: Aurelien Jarno <<a href="mailto:aurelien@aurel32.net" target="_blank">aurelien@aurel32.net</a>><br>
Cc: Gnuk and NeuG <<a href="mailto:gnuk-users@lists.alioth.debian.org" target="_blank">gnuk-users@lists.alioth.debia<wbr>n.org</a>><br>
Subject: Re: [Gnuk-users] [PATCH 0/7] Gnuk: add support for Cortex M4<br>
        MCU<br>
Message-ID: <<a href="mailto:87fuahx89d.fsf@iwagami.gniibe.org" target="_blank">87fuahx89d.fsf@iwagami.gniibe<wbr>.org</a>><br>
Content-Type: text/plain<br>
<br>
Hello,<br>
<br>
I applied and pushed your changes.  I added ChangeLog entry, so that<br>
tar.gz source code distribution of Gnuk can be compliant to GPL for<br>
PolarSSL.<br>
<br>
Please note that Chopstx is not copyrighted by FSIJ.  Individuals<br>
can keep their own copyright.<br>
<br>
<br>
Simply put (along with the agreement to USB-IF),<br>
<br>
    In the front line to the people in hardware industry and its mind<br>
    set of product liability, FSIJ needs to insist Gnuk is under full<br>
    control of the organization.<br>
<br>
For me, attitude of some people who don't care about (supply chain of)<br>
software technology is questionable, but it seems that dependency to<br>
compiler, operating system, and libraries by external entities is OK,<br>
according to a practice of (some of hardware) people.<br>
<br>
It seems that the term "security hardware" matters for some people.<br>
<br>
<br>
Aurelien Jarno <<a href="mailto:aurelien@aurel32.net" target="_blank">aurelien@aurel32.net</a>> wrote:<br>
> Yes, at least the ChaosKey is using the Openmoko VID. As far as I know<br>
> they use the fact that they signed the agreement with USB-IF *before*<br>
> transfers or subassignments were prohibited. That's also how pid.codes<br>
> [0] offers PID to free software projects.<br>
><br>
> [0] <a href="http://pid.codes" rel="noreferrer" target="_blank">http://pid.codes</a><br>
<br>
Thank for the information.  I didn't know that.  Today, I found<br>
more naughty one:  <a href="https://f055.io/" rel="noreferrer" target="_blank">https://f055.io/</a><br>
<br>
I also find this one today:<br>
<br>
<a href="https://www.mcselec.com/index.php?page=shop.product_details&flypage=shop.flypage&product_id=92&option=com_phpshop&Itemid=1" rel="noreferrer" target="_blank">https://www.mcselec.com/index.<wbr>php?page=shop.product_details&<wbr>flypage=shop.flypage&product_i<wbr>d=92&option=com_phpshop&Itemid<wbr>=1</a><br>
<br>
It seems that selling is more risky.<br>
<br>
<br>
> Do you think it would be possible to allow any PID with VID 6666 which<br>
> is for the prototype product vendor ID? It's of course not possible to<br>
> sell a device with such an ID, nor it would be possible for Debian to<br>
> distribute binaries with such an ID. On the other hand it's very useful<br>
> for personal use, and I use that for many of my other personal projects.<br>
<br>
If it works, it's OK, but vi-vi-vi-vi sounds like curse to Emacs users.<br>
<br>
I'm not sure if the VID is guaranteed by USB IF.  USB IF's offcial<br>
answer seems to be "please ask for VID assignment for prototype<br>
product".<br>
<br>
--<br>
In September 2013, Abe told Olympic dignitaries in Buenos Aires in an<br>
address that helped Tokyo win the 2020 Games:<br>
        "Let me assure you the situation is under control."<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Subject: Digest Footer<br>
<br>
______________________________<wbr>_________________<br>
gnuk-users mailing list<br>
<a href="mailto:gnuk-users@lists.alioth.debian.org" target="_blank">gnuk-users@lists.alioth.debian<wbr>.org</a><br>
<a href="https://lists.alioth.debian.org/mailman/listinfo/gnuk-users" rel="noreferrer" target="_blank">https://lists.alioth.debian.or<wbr>g/mailman/listinfo/gnuk-users</a><br>
<br>
<br>
------------------------------<br>
<br>
End of gnuk-users Digest, Vol 99, Issue 3<br>
******************************<wbr>***********<br>
</blockquote></div><br></div>
</blockquote></div><br></div>