I'm not sure I understand what you ask about rollup, but so far I haven't found a case I couldn't fit within Ledger. For VAT, I have a flat VAT rate that only applies to my turnover so it was simple to automate (reduce turnover by x% and put that amount into Owed VAT).
Nonnegative always includes zero, unless the author had muddled thinking themselves. Since positive is >0 and negative is <0, their negations are nonpositive for <=0 and nonnegative for >=0.
I wasn't precise enough. The Wikipedia page talks actually about "positive" integers, and I transformed this in my head to what should be written there.
I see your point too, and we're looking forward to a world in which low-power (to enable NFC) open source chips with security features exist. For instance, https://tropicsquare.com is a project that is working towards that.
For now, what we mean by open source hardware is on the one hand that all components are freely available (without NDAs, which nearly all secure elements entail), and on the other that the schematic of the device is open source and passes OSHWA Certification (the CERN license https://ohwr.org/project/cernohl/wikis/Documents/CERN-OHL-ve... is relevant here). This means that you can in principle build a device yourself. The certification will be done post-campaign (we want to avoid copycat products appearing before ours is available in the open market). Like we did with our three previous keys (e.g., https://certification.oshwa.org/us000155.html and https://github.com/solokeys/solo-hw).
Website can distinguish via the optional attestation key.
In terms of features, CTAP v2.1 (https://fidoalliance.org/specs/fido2/) is still draft only, but yes both v1 and v2 keys support hmac-secret and credential management. We could add authnSelection and authnConfig, but not clear if any browsers actually implement/use it.
The actual public key used for logging in to a specific site is completely random.
Optionally, the website can ask for "attestation", which is intended to prove that the public key is from a specific vendor/model. To make this also unlinkable, devices are supposed to share attestation keys in batches of 100k units.
Ah, I see! So cross-site (across multiple relying parties) linking is prevented but if I have multiple accounts within one relying party they can be linked?
FIDO (except in resident mode which we'll ignore here) requires the site requesting you authenticate to hand over a large opaque blob called an ID that your authenticator gave it when you enrolled the authenticator. This ID will be different for every time you enrolled an authenticator, and it can recognise its own IDs (using modern cryptography). To prevent you enrolling the same one twice, sites hand over a list of the ones you already enrolled and your authenticators say "I'm already enrolled here" if they recognise the ID.
So somesite.example if it suspects Jim and Candy are the same person, or at least, using the same FIDO authenticator, could do this:
When Jim signs in, they present Candy's ID. If they're right, Jim's authenticator goes "Oh I recognise this, signed". If they're wrong, Jim gets an error. Weird. Presumably on a second try they give Jim's ID and it works so that Jim isn't too suspicious.
So this attack would allow a site that strongly suspects you're doing this to prove it, to their own satisfaction anyway. But it doesn't offer any practical way for a site with more than a handful of users to just match all the users.
In resident mode, you have to admit who you are as part of signing in - you're not separately typing in an email address or username or whatever, you just press the button on your authenticator (or touch the sensor on your phone, or whatever) and you're in. This obviously means it doesn't make sense for Jim and Candy to use one device for two users on the site, and most likely their device will prohibit them from trying to enroll the second user this way.
Edited to add: If someothersite.example plays Jim or Candy's IDs from somesite.example (may it's secretly run by the same people, or they stole a database backup) to Jim (or Candy) they don't work, the IDs are bound to the domain, so these don't match.
I implemented this mode in a Django library [0] (demo on www.pastery.net) because I love the idea of not needing a password manager any more, just simply having a key with you to log in anywhere, but it doesn't seem to have widespread browser support yet.
Maybe I made a mistake, but Firefox doesn't seem to work very reliably with it, and mobile support is spotty too.
Yes, resident credential (aka "Client discoverable") support in (at least) desktop Firefox is broken and has been for a long time. I believe it's also absent (but at least not broken) in desktop Chrome. :/
We hope and think that PIV can replace all the practical use cases for PGP. Specifically among those mentioned, `age` for file encryption, and either FIDO resident keys with hmac-secret for password managers, or something like `passage` (fork of `pass` using, again, `age` for encryption). For SSH you can use FIDO for newer OpenSSH, and either `pivy` or `yubikey-agent` via PIV. Cheers!
As a reluctant PGP user who has backed Solo Keys v2 for 4+ for personal use, and who has written Rust code in the pursuit of using PIV over OpenPGP, this answer is disappointing.
Age isn't there. It does NOT have good (read, right now, really, any) support for hardware tokens. I'm skeptical of what I've seen. And age still punts on authentication. And PIV still doesn't have decent keys at decent sizes standardized and thus is awkward to use in practice.
I'm really not convinced, and I really want to be. I wrote a bunch of forward-looking Rust, and then permanently backburner-ed it because age/yubikey just isn't there yet.
Using FIDO2 for SSH, when you're used to the portability and versatility of OpenPGP, stinks. I can use my Yubikey perfectly to do SSH and GPG in Windows. I can forward SSH agent and GPG from Windows to Linux such that it is identical in functionality to me sitting in front of my actual Linux box with my Yubikey plugged in. I have never seen that done with PIV.
I have this extreme fear that I'm going to wind up with four solokeysv2 that just sit in a drawer.
I can't see why one would bother. OpenPGP works and is a published standard that has been around forever. Age is just pointlessly different with fewer use cases. This has an example of where age is objectively worse:
People like to dislike PGP and replace it with a myriad of different solutions. But PGP is everywhere and awesome. It's very wide spread adoption is invaluable. I really don't want to see it replaced with zillions of different bespoke solutions.
Yep! It's magical having everything signed automatically by plugging in my Yubikey and setting some git config once. I will not go to something that doesn't enable this.
This. I’m a backer for their Kickstarter but the lack of PGP is unfortunate. Yes, there are problems with it. But as you said, it’s everywhere. It’s not going anywhere anytime soon, so what’s the harm in supporting it for now?
Because it has a shitton of issues. The implementations aren't great, cryptographic issues, memory safety issues, stable API/ABI issues. It's still not supported well by software that could use these features.
Understood and it probably can but I don't want to replace it :) I like OpenPGP (especially the newer revision which supports elliptic curve).
The GPG toolchain is pretty great for file encryption and I use it for my password manager too (which is indeed ZX2C4 Pass - passwordstore.org ). I don't want to use a fork using 'age' because I rely on the GPG version on my mobile (using the excellent OpenKeyChain app and the passwordstore app which talks to that).
Also, I log in to SSH servers I don't have the ability to install stuff on, like the ILO on my servers. And again on mobile, there's bridges to OpenKeyChain for SSH in e.g. Termux which work great including agent forwarding. But not for PIV. So it's not a complete replacement.
Sorry but without OpenPGP it's a non-starter for me. I understand I could use Solokey if I make a lot of changes in my personal setup and make some compromises especially on mobile. But why would I? I can just continue using Yubikey :) Don't forget you're in a heavily contested market, you should be better than the competition.
I'd like to have an open-source authentication key but in the end it's a tool to me. Open-source is a 'nice to have'. It's not worth it to me to deviate too much from my existing workflow.
I believe the Burnside quote comes from the preface of his 1897 book:
> It may then be asked why, in a book which professes to leave all applications on one side, a considerable space is devoted to substitution groups; while other particular modes of representation, such as groups of linear transformations, are not even referred to. My answer to this question is that while, in the present state of our knowledge, many results in the pure theory are arrived at most readily by dealing with properties of substitution groups, it would be difficult to find a result that could be most directly obtained by the consideration of groups of linear transformations.
Your linked post is not about faking PGP, it is about replacing PGP with his own implementation which supports only a subset of the PGP standard, the subset necessary to properly sign git commits.
I've not made myself very clear in the comment, but git and fossil scm are simply examples that delegate issues of trust to PGP's web of trust. Hardware keys are more secure, but from my understanding still stuffer from the same issue PGP does - a physical device is not an identity. keys.pub looks very interesting, but it seems that like keybase it doesn't address everyone's concerns[0].
From a technical perspective if keys.pub exists there's no reason that the proof process could occur at a layer above git rather than within git in some form of "social proof sidechain"-like structure.
I'm definitely going to keep an eye on key.pub, once they've addressed some of their coming soon items they'll be a very nice contender to keybase.
An odd way to put it, but yes, the simplicity of the OpenPGP standard is one of its greatest strengths. Somehow the standard has resisted just a ton of stuff that would be pointless over the long term over a great many years.
Specifically, https://google.aip.dev/assets/misc/ebnf-filtering.txt which is a modification of their common expression language https://github.com/google/cel-spec