Welcome Wycheproof users

[Thai Duong]

Hello everybody,

I'm Thai, one of the maintainers of the project. I just want to say hi and let you know that we maintainers are watching this list for support requests.

Please feel free to drop us a line if you have any question or trouble running the tests. You can also tell us what else you want to test (by filing a feature request in our GitHub repository).

Cheers,

Thai.

[grr...@gmail.com]

First off: Thank you! These tests are really interesting and I can't wait to use them.

However, I can't seem to create an issue in GitHub for some reason. The really big thing I would like to see is a way to build just the non-provider specific logic into a JAR so that I can easily consume it for use with other unit tests. The second thing would be (optional?) use of explicit providers (in the getInstance) method rather than mucking around with the installed providers. Related to that, it would be nice for the library to be able to distinguish between logic under test (which needs a specific provider, such as for Cipher objects) rather than less interesting logic (such as KeyFactory).

Once again. Thank you. This really is exciting.

Greg

[⛷ Thai Duong]

On Mon, Dec 19, 2016 at 1:00 PM, <grr...@gmail.com> wrote:

First off: Thank you! These tests are really interesting and I can't wait to use them.

However, I can't seem to create an issue in GitHub for some reason.

My apology, I forgot to enable issue tracker. Just enabled it now!

 

The really big thing I would like to see is a way to build just the non-provider specific logic into a JAR so that I can easily consume it for use with other unit tests.

Good idea. Could you please file a FR?

 

The second thing would be (optional?) use of explicit providers (in the getInstance) method rather than mucking around with the installed providers.

If we do this, I'm afraid that we cannot run the same tests against multiple providers.

 

Related to that, it would be nice for the library to be able to distinguish between logic under test (which needs a specific provider, such as for Cipher objects) rather than less interesting logic (such as KeyFactory).

I'm not sure I understand this idea. Could you please give me an example?

Cheers,

Thai.

 

Once again. Thank you. This really is exciting.

Greg

On Monday, December 19, 2016 at 8:17:39 AM UTC-8, Thai Duong wrote:

Hello everybody,

I'm Thai, one of the maintainers of the project. I just want to say hi and let you know that we maintainers are watching this list for support requests.

Please feel free to drop us a line if you have any question or trouble running the tests. You can also tell us what else you want to test (by filing a feature request in our GitHub repository).

Cheers,

Thai.

--
You received this message because you are subscribed to the Google Groups "wycheproof-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wycheproof-users+unsubscribe@googlegroups.com.
To post to this group, send email to wycheproof-users@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/wycheproof-users/a92dd957-c032-4e7a-af68-195c28aa7618%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

https://vnhacker.blogspot.com

[Greg Rubin]

On Mon, Dec 19, 2016 at 4:23 PM ⛷ Thai Duong <tha...@gmail.com> wrote:

On Mon, Dec 19, 2016 at 1:00 PM, <grr...@gmail.com> wrote:

First off: Thank you! These tests are really interesting and I can't wait to use them.

However, I can't seem to create an issue in GitHub for some reason.

 

My apology, I forgot to enable issue tracker. Just enabled it now!

 

The really big thing I would like to see is a way to build just the non-provider specific logic into a JAR so that I can easily consume it for use with other unit tests.

Good idea. Could you please file a FR?

https://github.com/google/wycheproof/issues/3

 

 

The second thing would be (optional?) use of explicit providers (in the getInstance) method rather than mucking around with the installed providers.

If we do this, I'm afraid that we cannot run the same tests against multiple providers.

I don't understand what you mean here. Right now, your tests always execute against the default provide for each Service.Algorithm. If they were to take in a provider explicitly (either as a string or an object) then they could specifically target the providers associated with the test case. This variable would have to be passed in by the Runner or Provider-specific test-case/suite of course. Without this, I cannot run tests based on Wycheproof in the same JVM as other tests (as it will require stomping on provider list).

 

 

Related to that, it would be nice for the library to be able to distinguish between logic under test (which needs a specific provider, such as for Cipher objects) rather than less interesting logic (such as KeyFactory).

I'm not sure I understand this idea. Could you please give me an example?

Certainly. While more refactoring would be necessary to fix this, consider https://github.com/google/wycheproof/blob/master/java/com/google/security/wycheproof/testcases/EcdhTest.java#L871

 You're getting a KeyFactory for the "EC" algorithm from the default provider. (The default provider is currently the only provider as that's how your tests target specific providers.) However, this test doesn't actually care about the KeyFactory implementation, but rather the KeyAgreement implementation. This means that a more limited provider which only implements core cryptographic algorithms (such as KeyAgreement) while depending on other providers (such as SunEC) for data-formats (via KeyFactories) cannot be tested.  Does this make sense?  To fix this the following changes would need to be made (and I can file issues on them):

1) Separate tests such as the EcdhTest into multiple classes which more specifically target code bases. For example testDecode() and testModifiedPublic() should probably be in different files because one tests the KeyFactory and the other KeyAgreement

2) For the core components under test, use specific providers in the getInstance() method so that test (if they choose) can leave lower-priority providers present to implement supporting logic.

Greg

Cheers,

Thai.

 

Once again. Thank you. This really is exciting.

Greg

On Monday, December 19, 2016 at 8:17:39 AM UTC-8, Thai Duong wrote:

Hello everybody,

I'm Thai, one of the maintainers of the project. I just want to say hi and let you know that we maintainers are watching this list for support requests.

Please feel free to drop us a line if you have any question or trouble running the tests. You can also tell us what else you want to test (by filing a feature request in our GitHub repository).

Cheers,

Thai.

--
You received this message because you are subscribed to the Google Groups "wycheproof-users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to wycheproof-use...@googlegroups.com.
To post to this group, send email to wychepro...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/wycheproof-users/a92dd957-c032-4e7a-af68-195c28aa7618%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

https://vnhacker.blogspot.com

[bleichen]

On Tuesday, December 20, 2016 at 6:14:21 AM UTC+1, Greg Rubin wrote:

On Mon, Dec 19, 2016 at 4:23 PM ⛷ Thai Duong <tha...@gmail.com> wrote:

On Mon, Dec 19, 2016 at 1:00 PM, <grr...@gmail.com> wrote:

First off: Thank you! These tests are really interesting and I can't wait to use them.

However, I can't seem to create an issue in GitHub for some reason.

 

My apology, I forgot to enable issue tracker. Just enabled it now!

 

The really big thing I would like to see is a way to build just the non-provider specific logic into a JAR so that I can easily consume it for use with other unit tests.

Good idea. Could you please file a FR?

https://github.com/google/wycheproof/issues/3

 

 

The second thing would be (optional?) use of explicit providers (in the getInstance) method rather than mucking around with the installed providers.

If we do this, I'm afraid that we cannot run the same tests against multiple providers.

I don't understand what you mean here. Right now, your tests always execute against the default provide for each Service.Algorithm. If they were to take in a provider explicitly (either as a string or an object) then they could specifically target the providers associated with the test case. This variable would have to be passed in by the Runner or Provider-specific test-case/suite of course. Without this, I cannot run tests based on Wycheproof in the same JVM as other tests (as it will require stomping on provider list).

 

 

Related to that, it would be nice for the library to be able to distinguish between logic under test (which needs a specific provider, such as for Cipher objects) rather than less interesting logic (such as KeyFactory).

I'm not sure I understand this idea. Could you please give me an example?

Certainly. While more refactoring would be necessary to fix this, consider https://github.com/google/wycheproof/blob/master/java/com/google/security/wycheproof/testcases/EcdhTest.java#L871

 You're getting a KeyFactory for the "EC" algorithm from the default provider. (The default provider is currently the only provider as that's how your tests target specific providers.) However, this test doesn't actually care about the KeyFactory implementation, but rather the KeyAgreement implementation. This means that a more limited provider which only implements core cryptographic algorithms (such as KeyAgreement) while depending on other providers (such as SunEC) for data-formats (via KeyFactories) cannot be tested.  Does this make sense?  To fix this the following changes would need to be made (and I can file issues on them):

1) Separate tests such as the EcdhTest into multiple classes which more specifically target code bases. For example testDecode() and testModifiedPublic() should probably be in different files because one tests the KeyFactory and the other KeyAgreement

Good point.

There is already EcKeyTest.java, which should test the KeyFactory. 

At the moment I'm still trying to determine what parameter checks are expected from the KeyFactory and what checks should be done by the primitive.

This would allow to better divide the test vectors into "invalid keys" (should be detected by the KeyFactory)  and "modified keys" (should be detected by the primitive).

I'm also working on moving more tests into test vectors, so that porting to other languages would be simpler.

2) For the core components under test, use specific providers in the getInstance() method so that test (if they choose) can leave lower-priority providers present to implement supporting logic.

Currently the tests use  Security.removeProvider and Security.insertProviderAt to define the providers used.

That should give similar possibilities.

Using Security.insertProvider in the setup seems to be closer to most use cases where one doesn't specify the provider in the actual application.

Additionally, junit does make it easy to pass parameters to the test cases, (though here I'm not sure if I simply overlook something).

[⛷ Thai Duong]

On Mon, Dec 19, 2016 at 9:14 PM, Greg Rubin <grr...@gmail.com> wrote:

On Mon, Dec 19, 2016 at 4:23 PM ⛷ Thai Duong <tha...@gmail.com> wrote:

On Mon, Dec 19, 2016 at 1:00 PM, <grr...@gmail.com> wrote:

First off: Thank you! These tests are really interesting and I can't wait to use them.

However, I can't seem to create an issue in GitHub for some reason.

 

My apology, I forgot to enable issue tracker. Just enabled it now!

 

The really big thing I would like to see is a way to build just the non-provider specific logic into a JAR so that I can easily consume it for use with other unit tests.

Good idea. Could you please file a FR?

https://github.com/google/wycheproof/issues/3

Thanks! 

 

 

The second thing would be (optional?) use of explicit providers (in the getInstance) method rather than mucking around with the installed providers.

If we do this, I'm afraid that we cannot run the same tests against multiple providers.

I don't understand what you mean here. Right now, your tests always execute against the default provide for each Service.Algorithm. If they were to take in a provider explicitly (either as a string or an object) then they could specifically target the providers associated with the test case. This variable would have to be passed in by the Runner or Provider-specific test-case/suite of course. Without this, I cannot run tests based on Wycheproof in the same JVM as other tests (as it will require stomping on provider list).

Ah good point. We considered this approach but didn't see a need for it. What you wrote makes sense though. Could you please file another FR? Note that I won't be able to work on this until early January.

 

Related to that, it would be nice for the library to be able to distinguish between logic under test (which needs a specific provider, such as for Cipher objects) rather than less interesting logic (such as KeyFactory).

I'm not sure I understand this idea. Could you please give me an example?

Certainly. While more refactoring would be necessary to fix this, consider https://github.com/google/wycheproof/blob/master/java/com/google/security/wycheproof/testcases/EcdhTest.java#L871

 You're getting a KeyFactory for the "EC" algorithm from the default provider. (The default provider is currently the only provider as that's how your tests target specific providers.) However, this test doesn't actually care about the KeyFactory implementation, but rather the KeyAgreement implementation. This means that a more limited provider which only implements core cryptographic algorithms (such as KeyAgreement) while depending on other providers (such as SunEC) for data-formats (via KeyFactories) cannot be tested.  Does this make sense?  To fix this the following changes would need to be made (and I can file issues on them):

1) Separate tests such as the EcdhTest into multiple classes which more specifically target code bases. For example testDecode() and testModifiedPublic() should probably be in different files because one tests the KeyFactory and the other KeyAgreement

2) For the core components under test, use specific providers in the getInstance() method so that test (if they choose) can leave lower-priority providers present to implement supporting logic.

Greg

Cheers,

Thai.

 

Once again. Thank you. This really is exciting.

Greg

On Monday, December 19, 2016 at 8:17:39 AM UTC-8, Thai Duong wrote:

Hello everybody,

I'm Thai, one of the maintainers of the project. I just want to say hi and let you know that we maintainers are watching this list for support requests.

Please feel free to drop us a line if you have any question or trouble running the tests. You can also tell us what else you want to test (by filing a feature request in our GitHub repository).

Cheers,

Thai.

--
You received this message because you are subscribed to the Google Groups "wycheproof-users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to wycheproof-users+unsubscribe@googlegroups.com.
To post to this group, send email to wycheproof-users@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/wycheproof-users/a92dd957-c032-4e7a-af68-195c28aa7618%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

https://vnhacker.blogspot.com

--

https://vnhacker.blogspot.com

[Matt Borja]

Thanks for this! Hoping I'll be able to use them to improve upon an implementation I did on AES in C (Arduino) about a year ago: https://gist.github.com/rdev5/61219ccc80d64ba6394b

[Greg Rubin]

On Tue, Dec 20, 2016 at 7:39 AM bleichen <blei...@google.com> wrote:

Good point.

There is already EcKeyTest.java, which should test the KeyFactory. 

At the moment I'm still trying to determine what parameter checks are expected from the KeyFactory and what checks should be done by the primitive.

This would allow to better divide the test vectors into "invalid keys" (should be detected by the KeyFactory)  and "modified keys" (should be detected by the primitive).

I'm also working on moving more tests into test vectors, so that porting to other languages would be simpler.

I hope you have better luck than I here. So far, I've been unable to find any standards for what checks belong in the KeyFactory and what in the algorithms. I'd recommend a hard fail if the algorithm accepts a bad key and a warning if the KeyFactory accepts a bad key.  What would be very helpful here would be a KeyFactory known to perform no checking (perhaps provided by Wycheproof itself) specifically so you can get bad keys to the algorithms regardless of the checks provided elsewhere in the provider. Of course, if the Sun providers omit the checks, we can just use those.

 Greg