Results : 140

Now viewing page 1. Jump to : 

1. Re: Would minimal tests for importKey/exportKey be worthwhile? (score: 21) (14,575 bytes)
Author: Charles Engelke <w3c@engelke.com>, Date: Wed, 3 Aug 2016 11:46:27 -0400 List: Public/public-webcrypto
In-Reply-To: <CAFswn4kfawsM2wXEZ66E5TByEz_4b9d8KdeKOQdE5faqFALGXg@mail.gmail.com> References: 1 2

Okay, I'll work on this. As I said, all I'm really doing are minimal tests. I'm working on a fork of the test suite at https://github.com/engelke/web-platform-tests/tree/import_export . I'm happy to

2. Re: Would minimal tests for importKey/exportKey be worthwhile? (score: 16) (11,721 bytes)
Author: Eric Roman <ericroman@google.com>, Date: Tue, 2 Aug 2016 15:10:08 -0700 List: Public/public-webcrypto
In-Reply-To: <CAEnTvdBdNR0WBJN4yeMFbgQR4cL4NSjk3xiht9Q3awQwE4wPjg@mail.gmail.com> References: 1 2

I am strongly in favor of importKey()/exportKey() tests. I think these are crucial, since importKey()/exportKey() is a rich area for implementation incompatibilities/bugs. Some great areas to test he

3. HKDF and testing progress in general (score: 84) (5,884 bytes)
Author: Charles Engelke <w3c@engelke.com>, Date: Mon, 18 Jul 2016 15:47:25 -0400 List: Public/public-webcrypto

I've submitted pull requests 3183 ( https://github.com/w3c/web-platform-tests/pull/3183) and 3305 ( https://github.com/w3c/web-platform-tests/pull/3305) covering the sign, verify, deriveBits, and der

4. Re: Test progress and browser bug reports (score: 6) (3,826 bytes)
Author: Wendy Seltzer <wseltzer@w3.org>, Date: Fri, 8 Jul 2016 17:34:07 -0400 List: Public/public-webcrypto
In-Reply-To: <CAFeVzdw28gn8wLpCLZkbRsXMiiJV10GKGvjprN8PHt_Xeav8Zw@mail.gmail.com> References: 1

Thanks, Charlie! Great report and progress. --Wendy -- Wendy Seltzer -- wseltzer@w3.org +1.617.715.4883 (office) Policy Counsel and Domain Lead, World Wide Web Consortium (W3C) https://wendy.seltzer.

5. Test progress and browser bug reports (score: 6) (7,997 bytes)
Author: Charles Engelke <w3c@engelke.com>, Date: Fri, 8 Jul 2016 16:25:58 -0400 List: Public/public-webcrypto

I have tests for generateKey, digest, encrypt, decrypt, sign, and verify methods. I also have tests for deriveKey and deriveBits for PBKDF2 only. Except for PBKDF2 all these tests have either been me

6. Re: Testing encrypt with RSA-OAEP (score: 89) (11,348 bytes)
Author: Jason Proctor <jason@mono.hm>, Date: Thu, 2 Jun 2016 12:32:43 -0700 List: Public/public-webcrypto
In-Reply-To: <CAFswn4kDG2J_B25YrRudFk2r+fo3tBKygr2MAgBYSrFbnFUaZQ@mail.gmail.com> References: 1 2

thanks for the feedback. that does seem sensible - so much so, in fact, that i just did it. regards J

7. Re: Testing encrypt with RSA-OAEP (score: 99) (10,669 bytes)
Author: Eric Roman <ericroman@google.com>, Date: Thu, 2 Jun 2016 12:02:41 -0700 List: Public/public-webcrypto
In-Reply-To: <CAFeVzdyEd6UuyH9xHTHAa=KOStpHOi=bQxZjsxP-DFGYCro-fA@mail.gmail.com> References: 1 2

This approach SGTM.

8. Re: Testing encrypt with RSA-OAEP (score: 89) (9,995 bytes)
Author: Eric Roman <ericroman@google.com>, Date: Thu, 2 Jun 2016 12:01:37 -0700 List: Public/public-webcrypto
In-Reply-To: <CALQanAK7V1iYA=mogOj3o1EKn6NSBy_4ScL2MTjBsj1_AGCAMg@mail.gmail.com> References: 1 2

If you don't set the MGF using EVP_PKEY_CTX_set_rsa_mgf1_md(), then it looks like OpenSSL will just default to using the digest function set by EVP_PKEY_CTX_set_rsa_oaep_md() [1]. Should probably jus

9. Re: Testing encrypt with RSA-OAEP (score: 99) (6,224 bytes)
Author: Charles Engelke <w3c@engelke.com>, Date: Thu, 2 Jun 2016 14:56:35 -0400 List: Public/public-webcrypto
In-Reply-To: <CAFswn4=JXayYN4oTjZvc5FY2SMkY0Z2+Qe7QL1=8xjcCHocN6g@mail.gmail.com> References: 1 2

Thanks for both suggestions. Unless I hear objections, I'm going to go with testing via roundtripping in the browser, plus the extra checks Eric has mentioned. That avoid opening a whole can of worms

10. Re: Testing encrypt with RSA-OAEP (score: 94) (9,136 bytes)
Author: Eric Roman <ericroman@google.com>, Date: Thu, 2 Jun 2016 11:47:23 -0700 List: Public/public-webcrypto
In-Reply-To: <CAFeVzdwkpQ=zfTaLuvsUGVsCG+kx-27EjjOLeLikFP0+rH1P9g@mail.gmail.com> References: 1

I think this second option of round-tripping through decrypt is reasonable. We should also do some basic checks on the "shape" of the ciphertext -- namely verify its length, and that repeated encrypt

11. Re: Testing encrypt with RSA-OAEP (score: 89) (8,046 bytes)
Author: Jason Proctor <jason@mono.hm>, Date: Thu, 2 Jun 2016 11:16:00 -0700 List: Public/public-webcrypto
In-Reply-To: <CAFeVzdwkpQ=zfTaLuvsUGVsCG+kx-27EjjOLeLikFP0+rH1P9g@mail.gmail.com> References: 1

hi Charlie i've been using WebCrypto's RSA-OAEP/SHA-256 interchangeably with OpenSSL and Bouncy Castle, with complete success. for OpenSSL, i use RSA_PKCS1_OAEP_PADDING, but set the digest function t

12. Testing encrypt with RSA-OAEP (score: 89) (4,353 bytes)
Author: Charles Engelke <w3c@engelke.com>, Date: Thu, 2 Jun 2016 13:44:46 -0400 List: Public/public-webcrypto

I think I'm done testing encrypt for the various AES modes, and just have RSA-OAEP to go. But I'm running into a problem: RSA-OAEP injects randomness when encrypting, so the only way to check that en

13. Re: Pull request for IDL testing (score: 94) (8,531 bytes)
Author: Eric Roman <ericroman@google.com>, Date: Tue, 17 May 2016 12:48:32 -0700 List: Public/public-webcrypto
In-Reply-To: <02d801d1b074$025cdbf0$071693d0$@augustcellars.com> References: 1 2 3

Thanks Jim. Do you have a reduced test case I can run? Could be an issue with Blink's generic WebIDL bindings generator.

14. RE: Pull request for IDL testing (score: 84) (3,461 bytes)
Author: "Jim Schaad" <ietf@augustcellars.com>, Date: Tue, 17 May 2016 12:40:46 -0700 List: Public/public-webcrypto
In-Reply-To: <573B650C.4050406@mit.edu> References: 1 2

15. Re: Pull request for IDL testing (score: 89) (4,186 bytes)
Author: Boris Zbarsky <bzbarsky@mit.edu>, Date: Tue, 17 May 2016 14:38:04 -0400 List: Public/public-webcrypto
In-Reply-To: <02b401d1b068$d9af3280$8d0d9780$@augustcellars.com> References: 1

That's because of https://www.w3.org/Bugs/Public/show_bug.cgi?id=28244#c6 I would think. That doesn't explain the exceptions, though. Web crypto is not available in workers until Firefox 48, which is

16. Pull request for IDL testing (score: 84) (3,333 bytes)
Author: "Jim Schaad" <ietf@augustcellars.com>, Date: Tue, 17 May 2016 11:20:53 -0700 List: Public/public-webcrypto

17. RE: Testing progress for generateKey (score: 84) (4,542 bytes)
Author: "Jim Schaad" <ietf@augustcellars.com>, Date: Fri, 13 May 2016 23:17:17 -0700 List: Public/public-webcrypto
In-Reply-To: <CAFeVzdy8R1DEcOMOwQR657FJxMc9kTUn00ZCxiQM9XLTr4nE2g@mail.gmail.com> References: 1

18. Re: Testing progress for generateKey (score: 84) (7,918 bytes)
Author: Charles Engelke <w3c@engelke.com>, Date: Fri, 13 May 2016 20:44:48 -0400 List: Public/public-webcrypto
In-Reply-To: <CAFswn4nqAwDwHCpy9sfKC1vy_fwiey2Ft6wkHwYTq4t2vt8Waw@mail.gmail.com> References: 1 2

I agree with you completely. It seems to me to make more sense to check for empty usages at the start, when you do the other usages check. That's what Chrome does now. I'd certainly support changing

19. Re: Testing progress for generateKey (score: 84) (13,491 bytes)
Author: Eric Roman <ericroman@google.com>, Date: Fri, 13 May 2016 17:10:28 -0700 List: Public/public-webcrypto
In-Reply-To: <CAFswn4k4vz80eAZfnY88jxHO7HGq=V_6T3H8chg8TbaTexMv3w@mail.gmail.com> References: 1 2

A similar issue will apply to unwrapKey() -- Chrome verifies creation parameters before attempting to decrypt, in order to fail-fast if the import parameters are bogus. (So depending on the outcome o

20. Re: Testing progress for generateKey (score: 84) (12,090 bytes)
Author: Eric Roman <ericroman@google.com>, Date: Fri, 13 May 2016 17:02:19 -0700 List: Public/public-webcrypto
In-Reply-To: <CAFeVzdy8R1DEcOMOwQR657FJxMc9kTUn00ZCxiQM9XLTr4nE2g@mail.gmail.com> References: 1

Thanks Charles. I had previously filed this as a question against the spec: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27564 There was some commentary there, but no conclusive action (i.e. closin

Current List: 1 - 20 (of 140 results)

Now viewing page 1. Jump to :