Comments (7)
alex
commented on April 29, 2024
Would you accept a PR to x25519_test.json which marked any of the ones described as "public key with low order" as "Small public key"? Does the PR just get sent directly to that file?
from wycheproof.
thaidn
commented on April 29, 2024
from wycheproof.
bleichen
commented on April 29, 2024
I'm working on adding more flags.
Since flags are relatively new, not all the generation code has them.
Not sure yet, whether that status of some test vectors should be changed.
I.e., many of the test vectors with weak parameters (e.g. small IV sizes)
currently
have status "acceptable" because some libraries already reject weak
parameters.
It might be possible to ignore the fact that some parameters are weak and
simply
mark such test vectors are "valid" then let the tester decide if a failure
is due to
weak parameters based on the information in the header of the test group.
…On Wed, Jul 11, 2018 at 1:36 AM, Thai Duong ***@***.***> wrote:
@bleichen <https://github.com/bleichen>
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#59 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AYx_3lQN7Zjf5aR4H81wmxmTAivsiT6Pks5uFTptgaJpZM4VACSq>
.
from wycheproof.
davidben
commented on April 29, 2024
For BoringSSL, I think we're interested in:
- Excluding curves we don't support; the split up files are great, thanks!
- X25519 should compute the right answer in all cases, but there is a return value that corresponds to the all zero output. We're fine with the other "acceptable" inputs. (Per the formulation in RFC7748.)
- We don't allow explicit curve encodings in public keys. These are forbidden by RFC 5480.
- Our ASN.1 parsers are generally strict.
- We supported compressed coordinates.
- We are strict in the DigestInfo encoding in RSASSA-PKCS1-v1_5.
- We accept all specified IV lengths of AES-GCM and leave RSA key size limits for the caller to enforce. (The joys of being a low-level library with existing users... 😢)
Having weak parameters, at least for things like RSA keys, filtered out by either looking at the value or just splitting into files makes sense. I agree that weak things count more as "acceptable" than "valid", but I expect different libraries to have different cutoffs and whatnot for this, based on their needs, and so it may not be useful as a programmatically-checked status code on the test. Though it makes sense as something that could programmatically go either way; the main reason I'm interested in programmatically forcing the other "acceptable" inputs one way or another is the other cases, like bad ASN.1, are quite interesting to assert on.
from wycheproof.
bleichen
commented on April 29, 2024
On Wed, Jul 11, 2018 at 7:26 PM, David Benjamin ***@***.***> wrote:
For BoringSSL, I think we're interested in:
- Excluding curves we don't support; the split up files are great,
thanks!
That was the idea. Also the mixed files are becoming too large, so they
will eventually be reduced to test cases not covered in other files.
- X25519 should compute the right answer in all cases, but there is a
return value that corresponds to the all zero output. We're fine with the
other "acceptable" inputs. (Per the formulation in RFC7748.)
Not sure I understand this.
- We don't allow explicit curve encodings in public keys. These are
forbidden by RFC 5480.
Others do however. So it is necessary to test with such encodings. E.g.
one case was BouncyCastle, where it was possible to encode a public EC key
with
an incorrect order. One of the schemes (ECDHC) would check that the curves
for public and private key are the same by checking that a,b,p,... match
but then
reduce the private key modulo the order passed in with the public key.
Since the main goal is to find bugs that are exploitable, such test vectors
typically contain the shared ECDH result computed over the curve from the
private key.
Getting a different value is the most concerning test result.
- Our ASN.1 parsers are generally strict.
Any test case that is not DER encoded is at most "acceptable".
Making all BER encoded inputs invalid seems a bit premature, since there
are still a lot of libraries that are less strict.
Annotations are still weak, so that will be improved.
- We supported compressed coordinates.
Compressed and uncompressed coordiantes should probably be mixed in the
same files.
The question whether an implementation is vulnerable to attacks with public
key points not on the curve,
depends what formats the receiver accepts and not what the sender
generates.
- We are strict in the DigestInfo encoding in RSASSA-PKCS1-v1_5.
Well, everyone should.
- We accept all specified IV lengths of AES-GCM
I hope not IV length 0.
- and leave RSA key size limits for the caller to enforce. (The joys
of being a low-level library with existing users... 😢)
Which seems completely reasonable to me. I don't think it is the task of
the library maintainer to enforce new security limits.
Most libraries will have to support existing users with existing keys.
If restrictions are made then the key generation is a good place to start.
E.g., it isn't a problem if 1024 bit RSA keys are supported by a library.
But it is a problem if 1024 bits are the default
(or even any default).
Having weak parameters, at least for things like RSA keys, filtered out by
either looking at the value or just splitting into files makes sense. I
agree that weak things count more as "acceptable" than "valid", but I
expect different libraries to have different cutoffs and whatnot for this,
based on their needs, and so it may not be useful as a
programmatically-checked status code on the test. Though it makes sense as
something that could programmatically go either way; the main reason I'm
interested in programmatically forcing the other "acceptable" inputs one
way or another is the other cases, like bad ASN.1, are quite interesting to
assert on.
Finding good cut-off is indeed a problem. Since the parameter sizes are
also in the headers of the test groups it might be possible to drop this
distinction and just require that the tester
decides whether a failing test vector is due to weak parameters not
supported by the library.
… —
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#59 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AYx_3oY6C7o-CyOvLDzMQaK6niKZ3vkrks5uFjVYgaJpZM4VACSq>
.
from wycheproof.
davidben
commented on April 29, 2024
Others do however. So it is necessary to test with such encodings.
Oh, certainly! Sorry, that was probably unclear. I was just listing the things I would like to be able to differentiate via flags or checking parameters or some other mechanism.
from wycheproof.
NeilMadden
commented on April 29, 2024
Chiming in late to this issue, but if I can selfishly add my own wish it would be to have a way to distinguish between test cases (for signatures) that are needed to achieve strong unforgeability vs those needed for existential unforgeability.
I am seeing some test failures for lax parsing of ASN.1 DER for RSA signatures in Java (in particular allowing a constructed/concatenated OctetString in the DigestInfo structure). While it would be good for the cryptography provider to fix this, from our point of view we don't need canonical/unique signatures so I don't think this presents an exploitable issue in our scenario. For example, we also support ECDSA signatures that are malleable anyway. (Please correct me if I am misunderstanding this issue!)
from wycheproof.
Related Issues (20)
- Please update ecdh.md
- X448 vectors? HOT 5
- Test case P-384/P-521 bug from golang HOT 5
- Distinguish ECDSA malleability? HOT 12
- Fix Bazel Dependency HOT 1
- ChaCha20-Poly1305 large test vectors HOT 4
- When will you have an update on this project? HOT 1
- x448_test.json contains 57-byte public keys? HOT 1
- ind_cpa_test_schema.json: unused tagSize field HOT 1
- License Citation and Using Wycheproof Tests
- For more security spongycastle -> bouncycastle
- Add testcases for nettle ECDSA vulnerability
- Update public GitHub repo with latest version available
- OpenJDK tests no longer run on latest JDK versions HOT 1
- How to run Javascript tests?
- Minor feature request: unify JWK representations in JSON test vectors
- Make use of github actions
- No RsassaPkcs1Generate tests in testvectors_v1
- Support for ChaCha20 testvectors? HOT 9
- DsaTest.testTiming() could use a warmup HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from wycheproof.