I am working with informal systems on a tendermint light client to be used in the ibc protocol in parachains, we need use the polkadot host function for ed25519 signature verification for performance benefits, but we need substrate to migrate to ed25519-consensus instead of ed25519-dalek due to some inconsistencies in signature validation criteria in the ed25519-dalek's implementation of the ed25519 scheme, the issues are better explained in this article. https://hdevalence.ca/blog/2020-10-04-its-25519am
More details are specified in the readme here. https://github.com/penumbra-zone/ed25519-consensus
Related
I see a lot of videos showing withdrawals from ATMs with cloned EMV cards like code 201 so
how can be possible when a card uses DDA (dynamic keys) another question is cloned card just for magstripe because it is unencrypted or even EMV chip
It is a question that does not really belong to SO and due to the nature of what you are asking about, you may not receive a detailed answer. I will still try.
First of all, ATMs are online-only devices that do not need any form of Offline Data Authentication so DDA has little to do with them normally (there are exceptions from this rule, as usual).
There are still dynamic keys that are meant to provide security, nevertheless. A standard symmetric-key algorithm is used to generate online cryptogram and it is validated by the issuer. Symmetric keys are individual to each specific card and are not easily extracted (of course, nothing can be ever treated as 100% secure, but it would require a complex hardware attack to extract keys from a single card).
I assume your question about Service code 2xx, 5xx or 6xx is mostly revolving around magstripe data with no chip data available. In some situations (i.e. when card is mute) a fallback to magstripe transaction may happen. Normally, unattended devices should have this option blocked and decline such attempts but I would not bet there are no such devices around the world. You also need to consider that there are still devices that are not EMV-capable.
When it comes to magstripe data, they can be easily modified (for instance changing the service code) although such modification should be detectable. Same goes for using EMV track equivalent data on magstripe. In both cases, issuer is capable of detecting modification of the data or using it on different interface through the use of CVC/CVV which is encoded on a track and is created to cryptographically protect integrity of the track data. However, this requires to have proper implementation on the issuer side to detect and decline such attempts where cryptographic data from CVV or cryptogram are incorrect.
After watching Gavin's talk where he mentions private transactions in the Q&A, I started looking into if it's a thing on Substrate. I found this Parity Ethereum wiki article describing something similar. Is this currently possible on Substrate?
edit: I want to create encrypted transactions that only a selected number of peers can view. For each transaction this set might change.
AFAIK there is no such solution on Substrate as of the time of writing this post.
There are some privacy layers which are being built on Substrate such as Zero Chain:
Zerochain is a generic privacy-protecting layer on top of Substrate. It provides some useful substrate modules and toolkit for protecting user's privacy and sensitive data stored on chain. It is designed to get efficient zero-knowledge proving, reduce the on-chain storage cost and bring the flexibility for developing applications.
I don't think however, this attempts to solve the problem you are exactly describing.
I'm investigating about what would be a valid approach in order to provide a method to verify a user operation by his signature. The application must verify the user through it's fingertip signature, upon a particular action to be executed by him.
For the record, the user wil be previously signed in to the platform, this signature would be srot of a second factor authetication.
So far, I got two approches in mind:
The first one is not really good: Custom Vision. This service is
for classification, not verification, so it's a dead end.
On a second approach, I found MatLab exercises claiming to have a
solution, this youtube video explain (which seems to be quite
experimental and unofficial).
SecCodeCheckValidity:
Performs dynamic validation of signed code.
SecStaticCodeCheckValidity
Validates a static code object.
This function obtains and verifies the signature on the code specified
by the code object. It checks the validity of all sealed components,
including resources (if any). It validates the code against a code
requirement if one is specified. The call succeeds if all these
conditions are satisfactory. This call is only secure if the code is
not subject to concurrent modification, and the outcome is only valid
as long as the code remains unmodified. If the underlying file system
has dynamic characteristics, such as a network file system, union
mount, or FUSE, you must consider how secure the code is from
modification after validation.
So given this description for codesigning document from Apple, it is not clear what do they mean "dynamic characaterstics" here.
SecStaticCodeCheckValidity verifies if the application on-disk. In contrast, SecCodeCheckValidity verifies the application in-memory against the same requirements while it is running.
This attempts to prevent modification via hijacking, injection or other traditional methods of mutating in-memory code by checking if it is still code-signed with a valid signature.
I remember hearing that distinction somewhere during WWDC '09, correct me if I am wrong.
If you want to check whether some running code is signed by Apple and not some designated requirement specified by the programmer, you want:
SecRequirementCreateWithString(CFSTR("anchor apple"), ...)
and then pass the result from SecRequirementRef to SecCodeCheckValidity. There is no need to interact with the designated requirement in this case, since you've already decided what code is acceptable to you, which is anything signed by Apple.
In production code, you can use csreq(1) to compile a binary version of "anchor apple" and use SecRequirementCreateWithData instead of SecRequirementCreateWithString, which is faster.
Is there a cryptographic mechanism by which it is possible to sign a document with a date, such that it is not possible to forge that same signature at a later date? Maybe some sort of server that publishes daily cryptographic keys (but how can you trust them? ;-).
For the inevitable prodding pragmatists, I'm not trying to accomplish some task. I'm just curious what the solution space is like.
This is called Timestamping (TSP protocol, RFC 3161). Different digital signature standards (PDF and XML signatures, CAdES, PAdES, XAdES) include support for advanced timestamping based on TSP.
MS Authenticode also includes timestamping, but uses different (incompatible and less secure) mechanism for it.
TSP alone (without signature protocols) is not used a lot, but in conjunction with signature standards it becomes very handy.
GuardTime has an interesting service, where the timestamp does not depend on a trusted third party ("signed time") but can be independently verified by any interested party. It works somewhat similarly as Bitcoins, based on hash trees.