Home GnuPG

Weekly Standup
ActivePublic

Hosted by wk on Nov 20 2017, 11:00 AM - 12:00 PM.

Recurring Event

Event Series
This event is an instance of E232: Weekly Standup, and repeats every week.

Details

Event Timeline

  • Let me confirm:
  • Learned USB suspend/wakeup.
    • It should be fully-automatic.
    • Nothing needed for scdaemon implementation (provided it doesn't want to know these events).
      • USB suspend is supported by kernel USB driver. If it is supported, when no use of USB device, lsusb -v -d <HUB's PID:VID> can show the status of each port, like:
Hub Port Status:
   Port 1: 0000.0103 power enable connect
   Port 2: 0000.0107 power suspend enable connect
    • In USB suspend, no USB trafic. Device requires less current consumption (< 2.5mA by the spec)
    • Start of traffic (should) wakes up device from USB suspend.
    • Related but different
      • SUSPEND to RAM
        • configured device will fail after wakeup, if an application keeps using same FD. Application needs to close and open again.
        • behavior depends on HUB
          • Some recent root HUB supports power down on port, it seems
  • Gnuk support for USB suspend is ready (in master).
    • Chopstx supports sleep mode and lower clock (in master).
  • E236 on 11-27: will be absent (out of town to visit Tohoku area).
  • X448 for Gnuk at first
    • Field specific routines (mul, add, sqr, weak-reduce, strong-reduce), with 28-bit limb, avoiding carry
  • Plan
    • Then, implement in libgcrypt and GnuPG
      • How we introduce representation like 28-bit limb, it might differ (e.g., 56-bit for 64-bit arch) at compile time.
    • For EdDSA on 448 curve on Goldilocks field, we need more new things.

Yes, should be merged. But I think it is okay to merge several such things per day at once. Let's discuss this again.

Do we reuse the fd in scdaemon after a wakeup from suspend to RAM? Or is out error handler good enough to do this?
We should anyway send a HUP to gpg-agent before suspending to flush the caches.