Good morning Luke,
Another thing we can do with scan mode would be something like the below
masking:
input CLK, RESET_N;
input TESTMODE;
input SCANOUT_INTERNAL;
output SCANOUT_PAD;
reg gating;
wire n_gating = gating && TESTMODE;
always_ff @(posedge CLK, negedge
On Fri, Feb 12, 2021 at 9:36 AM Dmitry Petukhov wrote:
> If HUMAN_READABLE_TITLE is the additional secret, the user would need
> to enter it on the device in addition to the nonce, wouldn't it defeat
> the advantage in UX that was gained by using (relatively) short nonce ?
>
> Is 64 bit nonce
If HUMAN_READABLE_TITLE is the additional secret, the user would need
to enter it on the device in addition to the nonce, wouldn't it defeat
the advantage in UX that was gained by using (relatively) short nonce ?
Is 64 bit nonce not enough ?
It seems that to crack this with fixed Pwd and 64 bit
В Fri, 12 Feb 2021 18:42:31 +0100
Dmitry Petukhov wrote:
> Maybe for the UX it would be better to choose the number of rounds to
> use in PBKDF2, instead of using variable Pwd. Number of rounds will be
> easier to enter on the device (or just choose it from a set of
> pre-defined values). The
Thanks everyone who has provided inputs so far!
This is the new proposal for the encryption aspect of the scheme, based on
all the feedback.
The key derivation function would be PBKDF2, with PRF = SHA512. This should
be readily available on today's hardware already, as they are used for
BIP39.
Hard no to this idea:
On Thu, Feb 11, 2021 at 02:29:46PM -0800, Christopher Allen proposed:
...
> /48'/0'/0'/3'/PBKDF(complex string)'
As someone who has helped people find UTXO at key paths they didn't
know/want, this is a terrible idea. Key derivation paths should be
small, sequential
On Thu, Feb 11, 2021 at 3:05 PM Christopher Allen via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> What Blockchain Commons (and the Airgapped Wallet Community) call a policy
> map would be
>
> ```
> wsh(sortedmulti(1,,,))
> ```
>
> A PBKDF of that as would be unique for all 2 of
Hi Jeremy,
If I understand correctly your concern, you're worried that change would
ease discovery of the node's tx-relay topology ? I don't scope transaction
origin inference, if you suppose the
unrequested-tx peer sending is the attacker it must have learnt the
transaction from somewhere else
