On 8/18/2017 3:26 PM, Adam Petcher wrote:
On 8/17/2017 1:44 PM, Michael StJohns wrote:
See inline.
On 8/17/2017 11:19 AM, Adam Petcher wrote:
Specifically, these standards have properties related to byte arrays
like: "The Curve25519 function was carefully designed to allow all
32-byte stri
On 8/17/2017 1:44 PM, Michael StJohns wrote:
See inline.
On 8/17/2017 11:19 AM, Adam Petcher wrote:
Specifically, these standards have properties related to byte arrays
like: "The Curve25519 function was carefully designed to allow all
32-byte strings as Diffie-Hellman public keys."[1]
Th
On 8/17/2017 7:01 PM, Xuelei Fan wrote:
On 8/17/2017 11:35 AM, Michael StJohns wrote:
On 8/17/2017 1:28 PM, Xuelei Fan wrote:
This is the same for ANY current publicly known curve - different
providers may implement all some or none of them. So extending
this model for the curve25519 stuff is
On 8/17/2017 11:35 AM, Michael StJohns wrote:
On 8/17/2017 1:28 PM, Xuelei Fan wrote:
This is the same for ANY current publicly known curve - different
providers may implement all some or none of them. So extending this
model for the curve25519 stuff isn't going to be any different old
provid
On 8/17/2017 1:28 PM, Xuelei Fan wrote:
This is the same for ANY current publicly known curve - different
providers may implement all some or none of them. So extending this
model for the curve25519 stuff isn't going to be any different old
provider and new provider wise than is currently the
See inline.
On 8/17/2017 11:19 AM, Adam Petcher wrote:
On 8/16/2017 3:17 PM, Michael StJohns wrote:
On 8/16/2017 11:18 AM, Adam Petcher wrote:
My intention with this ByteArrayValue is to only use it for
information that has a clear semantics when represented as a byte
array, and a byte arr
On 8/17/2017 8:25 AM, Michael StJohns wrote:
On 8/16/2017 12:31 PM, Xuelei Fan wrote:
On 8/16/2017 8:18 AM, Adam Petcher wrote:
I don't worry about this issue any more. At present, each
java.security.Key has three characters (see the API Java doc):
. an algorithm
. an encoded form
. a forma
On 8/16/2017 12:31 PM, Xuelei Fan wrote:
On 8/16/2017 8:18 AM, Adam Petcher wrote:
I don't worry about this issue any more. At present, each
java.security.Key has three characters (see the API Java doc):
. an algorithm
. an encoded form
. a format
The format could be "X.509", and could be "
On 8/16/2017 3:17 PM, Michael StJohns wrote:
On 8/16/2017 11:18 AM, Adam Petcher wrote:
My intention with this ByteArrayValue is to only use it for
information that has a clear semantics when represented as a byte
array, and a byte array is a convenient and appropriate
representation for th
On 8/16/2017 11:18 AM, Adam Petcher wrote:
On 8/15/2017 7:05 PM, Michael StJohns wrote:
On 8/15/2017 1:43 PM, Xuelei Fan wrote:
On 8/11/2017 7:57 AM, Adam Petcher wrote:
I'm also coming to the conclusion that using X.509 encoding for
this sort of interoperability is too onerous, and we shoul
On 8/16/2017 8:18 AM, Adam Petcher wrote:
I don't worry about this issue any more. At present, each
java.security.Key has three characters (see the API Java doc):
. an algorithm
. an encoded form
. a format
The format could be "X.509", and could be "RAW" (like
ByteArrayValue.getValue()). I
On 8/15/2017 7:05 PM, Michael StJohns wrote:
On 8/15/2017 1:43 PM, Xuelei Fan wrote:
On 8/11/2017 7:57 AM, Adam Petcher wrote:
I'm also coming to the conclusion that using X.509 encoding for this
sort of interoperability is too onerous, and we should come up with
something better. Maybe we s
On 8/15/2017 5:29 PM, Anders Rundgren wrote:
Does this mean that the following is correct?
EC public key:
public interface ECPublicKey
extends PublicKey, ECKey
CFRG/RFC 7748 public key:
public class TheActualImplememtationClass
extends PublicKey, ByteArrayKey
Basically, yes. My latest pro
On 8/15/2017 1:43 PM, Xuelei Fan wrote:
On 8/11/2017 7:57 AM, Adam Petcher wrote:
On 8/10/2017 9:46 PM, Michael StJohns wrote:
On 8/10/2017 7:36 PM, Xuelei Fan wrote:
Right now there are 3 major APIs (JCA, PKCS11 and Microsoft CSP)
and at least 4 major representational domains (Raw, PKIX, XML
Does this mean that the following is correct?
EC public key:
public interface ECPublicKey
extends PublicKey, ECKey
CFRG/RFC 7748 public key:
public class TheActualImplememtationClass
extends PublicKey, ByteArrayKey
If so, it should work. Documentation seems a bit less obvious though
which i
On 8/11/2017 7:57 AM, Adam Petcher wrote:
On 8/10/2017 9:46 PM, Michael StJohns wrote:
On 8/10/2017 7:36 PM, Xuelei Fan wrote:
Right now there are 3 major APIs (JCA, PKCS11 and Microsoft CSP)
and at least 4 major representational domains (Raw, PKIX, XML and
JSON). In the current situation,
Okay, let me go back to the beginning with some slightly weaker
assumptions, and a slightly modified design. I've attempted to
incorporate all the feedback I've received so far, but if you feel like
I missed something, please let me know.
Assumptions:
A) We don't need to expose curve domain p
Hi Guys,
whatever you come up with I anticipate it comes with descriptions
of how to use it as well. I would recommend putting the JEP on GitHub
(although this may not be the usual process), since this topic have
bearings on other crypto APIs in the workings.
I really hope that the end-result wi
On 8/10/2017 12:25 PM, Michael StJohns wrote:
On 8/10/2017 9:44 AM, Adam Petcher wrote:
Does anyone know of a particular use case (that we haven't discuss
already) that would require a provider to support arbitrary curves?
Any other arguments for or against this feature?
There are uses for
On 8/10/2017 9:46 PM, Michael StJohns wrote:
On 8/10/2017 7:36 PM, Xuelei Fan wrote:
Right now there are 3 major APIs (JCA, PKCS11 and Microsoft CSP)
and at least 4 major representational domains (Raw, PKIX, XML and
JSON). In the current situation, I can take a JCA EC Public key and
convert
On 8/10/2017 6:46 PM, Michael StJohns wrote:
On 8/10/2017 7:36 PM, Xuelei Fan wrote:
Hi Michael,
Good points! See comments inlines.
On 8/10/2017 3:20 PM, Michael StJohns wrote:
Instead of converting, I was thinking about mapping. E.g. Montgomery
A and B matches the A and B of the curve.
On 8/10/2017 7:36 PM, Xuelei Fan wrote:
Hi Michael,
Good points! See comments inlines.
On 8/10/2017 3:20 PM, Michael StJohns wrote:
Instead of converting, I was thinking about mapping. E.g. Montgomery
A and B matches the A and B of the curve. But the "x" of the
Montgomery point is just t
Hi Michael,
Good points! See comments inlines.
On 8/10/2017 3:20 PM, Michael StJohns wrote:
Hi Xuelei -
Great analysis.
Some comments in line.
On 8/10/2017 3:10 PM, Xuelei Fan wrote:
Hi,
I want to extend the comment a little bit.
1. The background
A elliptic curve is determined by either
Hi Xuelei -
Great analysis.
Some comments in line.
On 8/10/2017 3:10 PM, Xuelei Fan wrote:
Hi,
I want to extend the comment a little bit.
1. The background
A elliptic curve is determined by either an equation of form
y^2 = x^3 + ax + b(1) [Weierstrass form]
or
y^2 + xy
Hi,
I want to extend the comment a little bit.
1. The background
A elliptic curve is determined by either an equation of form
y^2 = x^3 + ax + b(1) [Weierstrass form]
or
y^2 + xy = x^3 + ax^2 + b.(2)
However, some other forms may also be used. For example:
y^2 =
On 8/10/2017 9:44 AM, Adam Petcher wrote:
Does anyone know of a particular use case (that we haven't discuss
already) that would require a provider to support arbitrary curves?
Any other arguments for or against this feature?
There are uses for changing out the base point. PAKE and SPAKE use
Anyone have any additional thoughts on this?
I think the most significant item we need to discuss is the extent to
which JCA should allow curve parameters for RFC 7748/8032 to be
specified over the API. Does anyone know of a particular use case (that
we haven't discuss already) that would requ
On 8/8/2017 9:55 PM, Michael StJohns wrote:
Another option to consider is that we don't have subinterfaces for
RFC 7748 public/private keys, but rather we use some common
subinterface that provides enough information (e.g. the encoded
number and the curve parameters).
You mean like "ECKey
On 8/8/2017 5:00 PM, Adam Petcher wrote:
On 8/8/2017 12:50 PM, Michael StJohns wrote:
Further, this separation will reduce the probability of
programming errors (e.g. accidentally interpreting a Weierstrass
point as an RFC 7748 point).
Um. What? It actually won't.
This is the sort of
On 8/8/2017 12:50 PM, Michael StJohns wrote:
Further, this separation will reduce the probability of programming
errors (e.g. accidentally interpreting a Weierstrass point as an
RFC 7748 point).
Um. What? It actually won't.
This is the sort of problem I want to avoid:
KeyPairGenerator
On 2017-08-08 21:42, Xuelei Fan wrote:
On 8/8/2017 8:45 AM, Anders Rundgren wrote:
Object myOwnEncrypt(PublicKey publicKey) throws SecurityException {
if (publicKey instanceof RSAKey) {
// RSA
} else {
// It should be EC
}
}
The code above is not reliable unless on
On 8/8/2017 12:50 PM, Michael StJohns wrote:
We'll leave this for later. But generally, the JCA is a general
interface to a set of crypto primitives modeled on just a few key
types. To go in the direction you want to go it you need to explain
why its impossible to model an elliptic curve a
On 8/8/2017 8:45 AM, Anders Rundgren wrote:
On 2017-08-08 17:25, Adam Petcher wrote:
It sounds like what you are saying is
that I will need something like XDHPublicKey and XDHPrivateKey in
java.security.interfaces. Can you tell me why? What is it that we can't
do without these interfaces?
Eve
On 8/8/2017 11:45 AM, Anders Rundgren wrote:
On 2017-08-08 17:25, Adam Petcher wrote:
It sounds like what you are saying is
that I will need something like XDHPublicKey and XDHPrivateKey in
java.security.interfaces. Can you tell me why? What is it that we can't
do without these interfaces?
E
On 8/8/2017 11:25 AM, Adam Petcher wrote:
Thanks for the feedback. See below for my responses.
On 8/7/2017 5:52 PM, Michael StJohns wrote:
On 8/7/2017 4:37 PM, Adam Petcher wrote:
I'm working on the Java implementation of RFC 7748 (Diffie-Hellman
with X25519 and X448). I know some of you have
On 2017-08-08 17:25, Adam Petcher wrote:
It sounds like what you are saying is
that I will need something like XDHPublicKey and XDHPrivateKey in
java.security.interfaces. Can you tell me why? What is it that we can't
do without these interfaces?
Every JOSE Java library I have seen constructs a
Thanks for the feedback. See below for my responses.
On 8/7/2017 5:52 PM, Michael StJohns wrote:
On 8/7/2017 4:37 PM, Adam Petcher wrote:
I'm working on the Java implementation of RFC 7748 (Diffie-Hellman
with X25519 and X448). I know some of you have been anxious to talk
about how this would
On 2017-08-07 23:52, Michael StJohns wrote:
On 8/7/2017 4:37 PM, Adam Petcher wrote:
These two assumptions greatly simplify the API. We won't need classes
that mirror ECParameterSpec, EllipticCurve, ECPoint, ECField,
ECPublicKey, etc. for X25519/X448.
That assumption holds only if your vario
On 8/7/2017 4:37 PM, Adam Petcher wrote:
I'm working on the Java implementation of RFC 7748 (Diffie-Hellman
with X25519 and X448). I know some of you have been anxious to talk
about how this would fit into JCA, and I appreciate your patience
while I learned enough about JCA and existing crypto
I'm working on the Java implementation of RFC 7748 (Diffie-Hellman with
X25519 and X448). I know some of you have been anxious to talk about how
this would fit into JCA, and I appreciate your patience while I learned
enough about JCA and existing crypto implementations to develop this API
propo
40 matches
Mail list logo
