info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Public-key cryptosystem
118 views
Skip to first unread message
Daniel
Mar 30, 2020, 12:04:21 PM3/30/20
to
Hi, folks, this is my last public-key invention. Let's define it:
Let's first present the following substitution table:
int st[7][7]={
{3,5,2,4,0,6,1},
{1,6,5,2,4,3,0},
{5,4,0,1,3,2,6},
{0,3,6,5,2,1,4},
{6,2,4,0,1,5,3},
{2,0,1,3,6,4,5},
{4,1,3,6,5,0,2}};
This is c code, let's define the function f(a,b) as st[a][b], or what's
the same, the result of f(a,b) is the value in the row a and column b in
the table.
This function has been selected to be protected against linear
cryptoanalysis, the worst biassed linear equality has a probability in
the range of 0.42-0.62, near to the ideal 0.5. Differential
cryptoanalisys I think is not applicable or I don't know how to apply it
(no xor with the key).
After this, let's construct a mixing procedure.
The elements we're working with are list of N elements in the range
[0,6], or, to say it in another way a base-7 digit number with N digits.
Then t[i] or k[i] are the i-th digit of such a number, starting with the
units, or the i-th element on the list.
Then the mixing process, expressed as pseudocode, M multiple of N; This
is similar to the number of rounds of mixing, that would be M/N. t and k
are base-7 numbers with N digits.
function mix(t,k) returns t
for i in [0,N-1]:
t[i]=f(t[i],k[i])
for i in [0,M-1]:
t[i]=f(t[i],t[i-1]) // adjusting indexes to [0,N-1] if out of range
for i in [0,N-1]:
t[i]=f(t[i],k[i])
return t
As number of rounds is not as critical in asymmetric cryptography as in
symmetric, M can be 256*N, that's 256 rounds.
The hard problem is, with R=mix(T,K), knowing R and T find K.
This leads to a public-key cryptosystem, with key agreement and digital
signatures, described in:
https://github.com/danielnager/xifrat/blob/master/cryptosystem.pdf
Both f and mix have the property, for mix for example, that
mix(mix(a,b),mix(c,d))=mix(mix(a,c),mix(b,d)), a symmetric property that
is the basis of this cryptosystem.
And this how far I've got to an symmetric/asymmetric hibrid usable for
public key.
Advice and comments are welcomed.
Salut!
Daniel - daniel...@gmail.com
Let's first present the following substitution table:
int st[7][7]={
{3,5,2,4,0,6,1},
{1,6,5,2,4,3,0},
{5,4,0,1,3,2,6},
{0,3,6,5,2,1,4},
{6,2,4,0,1,5,3},
{2,0,1,3,6,4,5},
{4,1,3,6,5,0,2}};
This is c code, let's define the function f(a,b) as st[a][b], or what's
the same, the result of f(a,b) is the value in the row a and column b in
the table.
This function has been selected to be protected against linear
cryptoanalysis, the worst biassed linear equality has a probability in
the range of 0.42-0.62, near to the ideal 0.5. Differential
cryptoanalisys I think is not applicable or I don't know how to apply it
(no xor with the key).
After this, let's construct a mixing procedure.
The elements we're working with are list of N elements in the range
[0,6], or, to say it in another way a base-7 digit number with N digits.
Then t[i] or k[i] are the i-th digit of such a number, starting with the
units, or the i-th element on the list.
Then the mixing process, expressed as pseudocode, M multiple of N; This
is similar to the number of rounds of mixing, that would be M/N. t and k
are base-7 numbers with N digits.
function mix(t,k) returns t
for i in [0,N-1]:
t[i]=f(t[i],k[i])
for i in [0,M-1]:
t[i]=f(t[i],t[i-1]) // adjusting indexes to [0,N-1] if out of range
for i in [0,N-1]:
t[i]=f(t[i],k[i])
return t
As number of rounds is not as critical in asymmetric cryptography as in
symmetric, M can be 256*N, that's 256 rounds.
The hard problem is, with R=mix(T,K), knowing R and T find K.
This leads to a public-key cryptosystem, with key agreement and digital
signatures, described in:
https://github.com/danielnager/xifrat/blob/master/cryptosystem.pdf
Both f and mix have the property, for mix for example, that
mix(mix(a,b),mix(c,d))=mix(mix(a,c),mix(b,d)), a symmetric property that
is the basis of this cryptosystem.
And this how far I've got to an symmetric/asymmetric hibrid usable for
public key.
Advice and comments are welcomed.
Salut!
Daniel - daniel...@gmail.com
Samuel Allan
Mar 31, 2020, 6:39:51 AM3/31/20
to
On Monday, March 30, 2020 at 12:04:21 PM UTC-4, Daniel wrote:
> Hi, folks, this is my last public-key invention. Let's define it:
>
> Let's first present the following substitution table:
Very interesting idea. I myself was looking forward to somebody
> Hi, folks, this is my last public-key invention. Let's define it:
>
> Let's first present the following substitution table:
thinking of this approach to assymetric crypto.
I will take a look at it and attempt some cryptoanalysis this week.
Daniel
Mar 31, 2020, 11:35:59 AM3/31/20
to
El 31/3/20 a les 12:39, Samuel Allan ha escrit:
Thank you, take your time.
Daniel
Mar 31, 2020, 11:37:37 AM3/31/20
to
El 31/3/20 a les 12:39, Samuel Allan ha escrit:
Chris M. Thomasson
Mar 31, 2020, 3:33:20 PM3/31/20
to
On 3/31/2020 3:39 AM, Samuel Allan wrote:
> On Monday, March 30, 2020 at 12:04:21 PM UTC-4, Daniel wrote:
>> Hi, folks, this is my last public-key invention. Let's define it:
>>
>> Let's first present the following substitution table:
>
> Very interesting idea. I myself was looking forward to somebody
> thinking of this approach to assymetric crypto.
Agreed. I have had some bad luck with asymmetric crypto. Still wondering
> On Monday, March 30, 2020 at 12:04:21 PM UTC-4, Daniel wrote:
>> Hi, folks, this is my last public-key invention. Let's define it:
>>
>> Let's first present the following substitution table:
>
> Very interesting idea. I myself was looking forward to somebody
> thinking of this approach to assymetric crypto.
if its okay to combine asymmetric and symmetric. Wondering if it would
be kind of like using the same secret key for encrypting plaintext and
for sending the validating HMAC of the resulting ciphertext in the clear.
allan...@gmail.com
Apr 9, 2020, 12:32:05 AM4/9/20
to
I don't think those are related.
The reason you probably shouldn't
use the same key for hmac and encryption
is quite specific, whereas I see no
reason why you can't implement assymetric
crypto in a symmetric style.
The reason you probably shouldn't
use the same key for hmac and encryption
is quite specific, whereas I see no
reason why you can't implement assymetric
crypto in a symmetric style.
Daniel
Apr 10, 2020, 1:32:33 PM4/10/20
to
El 9/4/20 a les 6:32, allan...@gmail.com ha escrit:
Mix up public-key session establishment with hmac one is a common
mistake, I guess. The difference is the absence or presence of a
preshared secret. Further, with hmac you can't do public signatures,
just peer-to-peer autentification.
So, have a nice day and happy trolling.
Daniel
PS: My algorithm? It's curious and interesting but I'm not fighting a
lot for it. Anyone?
mistake, I guess. The difference is the absence or presence of a
preshared secret. Further, with hmac you can't do public signatures,
just peer-to-peer autentification.
So, have a nice day and happy trolling.
Daniel
PS: My algorithm? It's curious and interesting but I'm not fighting a
lot for it. Anyone?
tranng...@gmail.com
Apr 17, 2020, 6:13:38 AM4/17/20
to
Hello,
I've read the documentation and have questions:
1) The mix(x,y) function, described here, and the m(x,y) function described by the documentation, are not the same: m(x,y) has pre-whitening while mix() has both pre- and post- whitening. So I understand that that mix() is intended to be the improved version of m(). Is it correct?
2) Does the 'restrict commutativity' property, claimed to hold for m() by the documentation, still hold for mix()?
3) The round function mixes the state string (R) with a permuted version of the string (R permuted). The specific permutation is string rotation. Does the 'restrict commutativity' property still hold if the rotation is replaced with another permutation, e.g. decimation?
4) The entire construction, mix(x,z), has a special algebraic property, namely the 'restrict commutativity' property. On the other hand it is constructed as a product (i.e. multi-round) cipher which, as implied by security requirements, a symmetric (secret-key) block cipher with key length = text length. Am I understanding correctly?
Daniel
Apr 18, 2020, 7:55:42 AM4/18/20
to
El 17/4/20 a les 12:13, tranng...@gmail.com ha escrit:
Hi, let's work a little. Thank you for your attention.
up to date. I've chosen pre and post whitening because is simpler to
explain and, correct me if I'm wrong, safety is the same.
> 2) Does the 'restrict commutativity' property, claimed to hold for m() by the documentation, still hold for mix()?
Yes. Let me say that it's the property that justifies everything and
allows for public-key protocols, key agreement and signature.
>
> 3) The round function mixes the state string (R) with a permuted version of the string (R permuted). The specific permutation is string rotation. Does the 'restrict commutativity' property still hold if the rotation is replaced with another permutation, e.g. decimation?
Well, it's not exactly string rotation. In this case the m (mixing)
function will not be reversible knowing the ciphertext and the key. The
mixing applies f (the 7x7 substitution table) sequentially to adjacent
elements in the string, while trying to accumulate diffusion. So, if s
is the state, the process is:
N=length(s)
s[0]=f(s[0],s[-1]) // s[-1]=s[length(s)-1]
s[1]=f(s[1],s[0])
s[2]=f(s[2],s[1])
...
and so on, wrapping at the end.
Another permutations are possible but always updating i.e. doing
s[a]=f(s[a],s[b]). I've not written a formal proof but my experiments
points to this.
>
> 4) The entire construction, mix(x,z), has a special algebraic property, namely the 'restrict commutativity' property. On the other hand it is constructed as a product (i.e. multi-round) cipher which, as implied by security requirements, a symmetric (secret-key) block cipher with key length = text length. Am I understanding correctly?
>
Yes again. The name of the property is quite random. The answer to the
second question is yes. I've nothing to add since you're describing it
very accurately. The difference with a symmetric cypher is that's much
simpler, which is not and advantage but a constraint. In the end is a
public-key, asymmetric, algorithm, so it must hold the property
'restricted commutativity' in order to be useful. The good point is that
the number of rounds is not critical, or at least can be big, 256 rounds
is ok, for example (here I'm considering a round a full cycle over the
state). Speed is not critical in public key cryptography (if it's not
absurdly slow, of course).
Yours,
Daniel
>
> I've read the documentation and have questions:
>
> 1) The mix(x,y) function, described here, and the m(x,y) function described by the documentation, are not the same: m(x,y) has pre-whitening while mix() has both pre- and post- whitening. So I understand that that mix() is intended to be the improved version of m(). Is it correct?
>
Absolutely. It's an improved version, simpler. The documentation is not
> I've read the documentation and have questions:
>
> 1) The mix(x,y) function, described here, and the m(x,y) function described by the documentation, are not the same: m(x,y) has pre-whitening while mix() has both pre- and post- whitening. So I understand that that mix() is intended to be the improved version of m(). Is it correct?
>
up to date. I've chosen pre and post whitening because is simpler to
explain and, correct me if I'm wrong, safety is the same.
> 2) Does the 'restrict commutativity' property, claimed to hold for m() by the documentation, still hold for mix()?
allows for public-key protocols, key agreement and signature.
>
> 3) The round function mixes the state string (R) with a permuted version of the string (R permuted). The specific permutation is string rotation. Does the 'restrict commutativity' property still hold if the rotation is replaced with another permutation, e.g. decimation?
function will not be reversible knowing the ciphertext and the key. The
mixing applies f (the 7x7 substitution table) sequentially to adjacent
elements in the string, while trying to accumulate diffusion. So, if s
is the state, the process is:
N=length(s)
s[0]=f(s[0],s[-1]) // s[-1]=s[length(s)-1]
s[1]=f(s[1],s[0])
s[2]=f(s[2],s[1])
...
and so on, wrapping at the end.
Another permutations are possible but always updating i.e. doing
s[a]=f(s[a],s[b]). I've not written a formal proof but my experiments
points to this.
>
> 4) The entire construction, mix(x,z), has a special algebraic property, namely the 'restrict commutativity' property. On the other hand it is constructed as a product (i.e. multi-round) cipher which, as implied by security requirements, a symmetric (secret-key) block cipher with key length = text length. Am I understanding correctly?
>
second question is yes. I've nothing to add since you're describing it
very accurately. The difference with a symmetric cypher is that's much
simpler, which is not and advantage but a constraint. In the end is a
public-key, asymmetric, algorithm, so it must hold the property
'restricted commutativity' in order to be useful. The good point is that
the number of rounds is not critical, or at least can be big, 256 rounds
is ok, for example (here I'm considering a round a full cycle over the
state). Speed is not critical in public key cryptography (if it's not
absurdly slow, of course).
Yours,
Daniel
Chris M. Thomasson
Apr 18, 2020, 6:59:25 PM4/18/20
to
secret after asymmetric key exchange? This generated key and the
ciphertext can be known because its hard to get at the original
asymmetric exchange? Is it safe to integrate asymmetric and symmetric
encryption?
[...]
Rich
Apr 19, 2020, 12:23:42 AM4/19/20
to
Chris M. Thomasson <chris.m.t...@gmail.com> wrote:
> Is it safe to integrate asymmetric and symmetric encryption?
I'll let Daniel comment on your questions that are directed to his
> Is it safe to integrate asymmetric and symmetric encryption?
latest algorithm.
But, on this question, yes, it is safe. In fact, this is the
construction that allmost all of the existing "public key" systems in
general use (i.e., PGP/GPG and friends) utilize.
For Alice to encrypt a message to Bob, she obtains (somehow) Bob's
public key.
Then, she creates a random cipher key K, for a conventional symmetric
algorithm (AES) and encrypts her message M using key K: SE=AES(M,K).
Then, she takes the key K for the symmetric encrypted message SE and
encrypts the key to that message, K, using Bob's public key (Bpk) using
the asymetric algorithm: AEK=RSA(K,Bpk) (RSA picked as just a well
known algorithm).
Then, Alice transmits AEK and SE to Bob.
Bob, to read the message, just decrypts in reverse order of how Alice
encrypted.
The reason this is the conventional construction is that many (most?)
of the asymetric algorithms are quite slow, esp. when
encrypting/decrypting large amounts of data. I.e., for RSA you need to
not only operate upon 2048 or 4096 bit keys, but you also have to
consider the message itself as a "message bit size" integer number, and
perform the required math on that really big number.
By using the asymetric algorithm to encrypt a key for a symmetric
algorithm, the amount of data the asymetric algorithm has to consume is
much smaller (a 128 or 256 bit AES key) and so the process can proceed
at a much faster rate, and need a lot less computer memory than is
otherwise required to hold really huge integers and then
multiply/divide and raise to powers those huge integers.
Daniel
Apr 19, 2020, 9:15:29 AM4/19/20
to
El 19/4/20 a les 0:59, Chris M. Thomasson ha escrit:
ambiguous term, unlike symmetric. Can refer to actually encrypting
something, as in RSA, or just to get a shared secret that can be used in
a session using symmetric crypto, as in Diffie-Hellman. My proposal of
algorithm just does a Diffie-Hellman, despite my use (or misuse) of the
terms plaintext and ciphertext. Also a digital signature is proposed.
So you have a function m(a,b) with complexity and a and b having say 256
bits roughly. I assume to be hard if we get a result r=m(a,b), to
recover b knowing only r and a. Hence the terms of symmetric crypto. b
in r=m(a,b) plays the role of a key and is secret information. Public
information are the algorithm itself and a.
To create a shared secret:
Both Alice and Bob agree on a public value, let's call it P.
Alice chooses a key Ka and sends to Bob Ia=m(P,Ka)
Bob does the same so sends to alice Ib=m(P,Kb), where Kb is Bob secret key.
Then Alice computes privately S=m(Ib,m(Ka,P))=m(m(P,Kb),m(Ka,P))
Bob at his turn does the same, S=m(Ia,m(Kb,P)=m(m(P,Ka),m(Kb,P))
Both S are the same due to the 'restricted commutativity' property that
stands that m(m(a,b),m(c,d))=m(m(a,c),m(b,d)).
Eve must solve the hard problem above to get both Ka and Kb, which are
secret information hold by Alice and Bob.
With S you start transmitting information with your favorite symmetric
cypher.
And why all this: 1 Just pass time, 2 Shor's algorithm can't be applied
with the consequences this has, 3 Small in bits signatures
Cheers,
Daniel
> On 4/18/2020 4:55 AM, Daniel wrote:
>> El 17/4/20 a les 12:13, tranng...@gmail.com ha escrit:
>>> On Monday, March 30, 2020 at 11:04:21 PM UTC+7, Daniel wrote:
>>>> Hi, folks, this is my last public-key invention. Let's define it:
>>>>
<snip>
>> El 17/4/20 a les 12:13, tranng...@gmail.com ha escrit:
>>> On Monday, March 30, 2020 at 11:04:21 PM UTC+7, Daniel wrote:
>>>> Hi, folks, this is my last public-key invention. Let's define it:
>>>>
>
> Sorry for the stupid question: Is this key the result of the shared
> secret after asymmetric key exchange? This generated key and the
> ciphertext can be known because its hard to get at the original
> asymmetric exchange? Is it safe to integrate asymmetric and symmetric
> encryption?
>
> [...]
The answer: NO! But thanks to ask. Public key, or asymmetric, is an
> Sorry for the stupid question: Is this key the result of the shared
> secret after asymmetric key exchange? This generated key and the
> ciphertext can be known because its hard to get at the original
> asymmetric exchange? Is it safe to integrate asymmetric and symmetric
> encryption?
>
> [...]
ambiguous term, unlike symmetric. Can refer to actually encrypting
something, as in RSA, or just to get a shared secret that can be used in
a session using symmetric crypto, as in Diffie-Hellman. My proposal of
algorithm just does a Diffie-Hellman, despite my use (or misuse) of the
terms plaintext and ciphertext. Also a digital signature is proposed.
So you have a function m(a,b) with complexity and a and b having say 256
bits roughly. I assume to be hard if we get a result r=m(a,b), to
recover b knowing only r and a. Hence the terms of symmetric crypto. b
in r=m(a,b) plays the role of a key and is secret information. Public
information are the algorithm itself and a.
To create a shared secret:
Both Alice and Bob agree on a public value, let's call it P.
Alice chooses a key Ka and sends to Bob Ia=m(P,Ka)
Bob does the same so sends to alice Ib=m(P,Kb), where Kb is Bob secret key.
Then Alice computes privately S=m(Ib,m(Ka,P))=m(m(P,Kb),m(Ka,P))
Bob at his turn does the same, S=m(Ia,m(Kb,P)=m(m(P,Ka),m(Kb,P))
Both S are the same due to the 'restricted commutativity' property that
stands that m(m(a,b),m(c,d))=m(m(a,c),m(b,d)).
Eve must solve the hard problem above to get both Ka and Kb, which are
secret information hold by Alice and Bob.
With S you start transmitting information with your favorite symmetric
cypher.
And why all this: 1 Just pass time, 2 Shor's algorithm can't be applied
with the consequences this has, 3 Small in bits signatures
Cheers,
Daniel
Daniel
Apr 19, 2020, 9:21:51 AM4/19/20
to
El 19/4/20 a les 6:23, Rich ha escrit:
Ehh. It can seem this is what I'm trying to do, it will be perfect. But
as I've explained to Chris is just a Diffie-Hellman, but resistant to
Shor's algorithm, and even Pollard-Rho. A digital signature protocol is
also on the documentation.
Cheers
Daniel
as I've explained to Chris is just a Diffie-Hellman, but resistant to
Shor's algorithm, and even Pollard-Rho. A digital signature protocol is
also on the documentation.
Cheers
Daniel
Chris M. Thomasson
Apr 19, 2020, 3:00:59 PM4/19/20
to
On 4/19/2020 6:15 AM, Daniel wrote:
> El 19/4/20 a les 0:59, Chris M. Thomasson ha escrit:
>> On 4/18/2020 4:55 AM, Daniel wrote:
>>> El 17/4/20 a les 12:13, tranng...@gmail.com ha escrit:
>>>> On Monday, March 30, 2020 at 11:04:21 PM UTC+7, Daniel wrote:
>>>>> Hi, folks, this is my last public-key invention. Let's define it:
>>>>>
> <snip>
>>
>> Sorry for the stupid question: Is this key the result of the shared
>> secret after asymmetric key exchange? This generated key and the
>> ciphertext can be known because its hard to get at the original
>> asymmetric exchange? Is it safe to integrate asymmetric and symmetric
>> encryption?
>>
>> [...]
>
> The answer: NO! But thanks to ask. Public key, or asymmetric, is an
> ambiguous term, unlike symmetric. Can refer to actually encrypting
> something, as in RSA, or just to get a shared secret that can be used in
> a session using symmetric crypto, as in Diffie-Hellman. My proposal of
> algorithm just does a Diffie-Hellman, despite my use (or misuse) of the
> terms plaintext and ciphertext. Also a digital signature is proposed.
Ahhhh! The word ciphertext confused me. For some damn reason I thought
> El 19/4/20 a les 0:59, Chris M. Thomasson ha escrit:
>> On 4/18/2020 4:55 AM, Daniel wrote:
>>> El 17/4/20 a les 12:13, tranng...@gmail.com ha escrit:
>>>> On Monday, March 30, 2020 at 11:04:21 PM UTC+7, Daniel wrote:
>>>>> Hi, folks, this is my last public-key invention. Let's define it:
>>>>>
> <snip>
>>
>> Sorry for the stupid question: Is this key the result of the shared
>> secret after asymmetric key exchange? This generated key and the
>> ciphertext can be known because its hard to get at the original
>> asymmetric exchange? Is it safe to integrate asymmetric and symmetric
>> encryption?
>>
>> [...]
>
> The answer: NO! But thanks to ask. Public key, or asymmetric, is an
> ambiguous term, unlike symmetric. Can refer to actually encrypting
> something, as in RSA, or just to get a shared secret that can be used in
> a session using symmetric crypto, as in Diffie-Hellman. My proposal of
> algorithm just does a Diffie-Hellman, despite my use (or misuse) of the
> terms plaintext and ciphertext. Also a digital signature is proposed.
you were integrating a symmetric cipher into the mix.
> So you have a function m(a,b) with complexity and a and b having say 256
> bits roughly. I assume to be hard if we get a result r=m(a,b), to
> recover b knowing only r and a. Hence the terms of symmetric crypto. b
> in r=m(a,b) plays the role of a key and is secret information. Public
> information are the algorithm itself and a.
>
> To create a shared secret:
>
> Both Alice and Bob agree on a public value, let's call it P.
> Alice chooses a key Ka and sends to Bob Ia=m(P,Ka)
> Bob does the same so sends to alice Ib=m(P,Kb), where Kb is Bob secret key.
Say, Alice chooses 301 random bytes for Ka, and Bob decides to use 509
bytes for Kb?
> Then Alice computes privately S=m(Ib,m(Ka,P))=m(m(P,Kb),m(Ka,P))
> Bob at his turn does the same, S=m(Ia,m(Kb,P)=m(m(P,Ka),m(Kb,P))
>
> Both S are the same due to the 'restricted commutativity' property that
> stands that m(m(a,b),m(c,d))=m(m(a,c),m(b,d)).
> Eve must solve the hard problem above to get both Ka and Kb, which are
> secret information hold by Alice and Bob.
>
> With S you start transmitting information with your favorite symmetric
> cypher.
>
> And why all this: 1 Just pass time, 2 Shor's algorithm can't be applied
> with the consequences this has, 3 Small in bits signatures
back. Your algorihtm needs to be studied. Afaict, you are trying to get
around a quantum-based attack that DH can theoretically fall to?
Rich
Apr 19, 2020, 3:04:52 PM4/19/20
to
Chris M. Thomasson <chris.m.t...@gmail.com> wrote:
> Ahhhh! The word ciphertext confused me. For some damn reason I
> thought you were integrating a symmetric cipher into the mix.
The word "ciphertext" is a generic term that means "the output of an
> thought you were integrating a symmetric cipher into the mix.
encryption system".
It gives no indication on the type or kind of encryption system used to
create that output. The output from symmetric, public key, and ceasar
ciphers are all generically "ciphertext".
Chris M. Thomasson
Apr 20, 2020, 4:06:28 AM4/20/20
to
secure than an asymmetric key exchange algo wrt parameters being sent in
the clear for all to see? In the secret meeting, no info is transmitted
across the wire to obtain the shared secret key. This is not the case
wrt any asymmetric key exchange?
FromTheRafters
Apr 20, 2020, 5:17:09 AM4/20/20
to
Chris M. Thomasson has brought this to us :
Of course having some other way to distribute keys securely is better
than relying on "hard" math protection, but that is not the point. The
point is to be able to do it while Eve watches the traffic between
Alice and Bob.
than relying on "hard" math protection, but that is not the point. The
point is to be able to do it while Eve watches the traffic between
Alice and Bob.
Rich
Apr 20, 2020, 10:38:28 AM4/20/20
to
secure either way.
Secret meeting method: Nothing is transmitted over a transmission
system, so an Eve can't intercept anything in transmission.
But, Eve could bug the room, and thereby obtain the secret key via that
method.
Key exchange: something is transmitted, hopefully something that is too
hard for Eve to decode, so that it does not matter if Eve intercepts or
not.
Method 1 (room) depends upon the security of the room.
Method 2 (exchange) depends upon the security of the exchange
algorithm.
So the security requirements are different, but both have 'angles' for
potential attack.
However, method 2 do not require Alice and Bob to be required to
transport themselves to the same room, which can be a huge benefit
(think the current 'lockdown' environment and drastic reduction in
travel).
Most consider the benefits of method 2 (do not need to travel to be in
same room together) a benefit that *far* outweighs the different
security profile of relying on the algorithm security vs. relying on
room physical security. Plus, if the algorithm has at least an equal
risk as the room of a breech, then there's no difference in security
profile, but with the added benefit of no travel required for the
algorithm.
Daniel
Apr 20, 2020, 12:50:19 PM4/20/20
to
El 19/4/20 a les 21:00, Chris M. Thomasson ha escrit:
asymmetric. I'm experimenting yet.
>
>> So you have a function m(a,b) with complexity and a and b having say
>> 256 bits roughly. I assume to be hard if we get a result r=m(a,b), to
>> recover b knowing only r and a. Hence the terms of symmetric crypto. b
>> in r=m(a,b) plays the role of a key and is secret information. Public
>> information are the algorithm itself and a.
>>
>> To create a shared secret:
>>
>> Both Alice and Bob agree on a public value, let's call it P.
>> Alice chooses a key Ka and sends to Bob Ia=m(P,Ka)
>> Bob does the same so sends to alice Ib=m(P,Kb), where Kb is Bob secret
>> key.
>
> Can Ka and Kb be comprised of arbitrarily sized random bytes?
>
> Say, Alice chooses 301 random bytes for Ka, and Bob decides to use 509
> bytes for Kb?
>
Ka and Kb must be the same size. And true random if possible, or a
considered reasonable pseudorandom source to generate keys like
/dev/urandom in linux.
>
>> Then Alice computes privately S=m(Ib,m(Ka,P))=m(m(P,Kb),m(Ka,P))
>> Bob at his turn does the same, S=m(Ia,m(Kb,P)=m(m(P,Ka),m(Kb,P))
>>
>> Both S are the same due to the 'restricted commutativity' property
>> that stands that m(m(a,b),m(c,d))=m(m(a,c),m(b,d)).
>> Eve must solve the hard problem above to get both Ka and Kb, which are
>> secret information hold by Alice and Bob.
>>
>> With S you start transmitting information with your favorite symmetric
>> cypher.
>>
>> And why all this: 1 Just pass time, 2 Shor's algorithm can't be
>> applied with the consequences this has, 3 Small in bits signatures
> Okay. Thank you. I remember trying an impl of an earlier version a while
> back. Your algorihtm needs to be studied. Afaict, you are trying to get
> around a quantum-based attack that DH can theoretically fall to?
>
Exactly. And I want to share it to other people to see if someone can
improve it in some way I can't. Particulary the 7x7 s-box, thought I
think is non-trivial is really small. A 31x31 s-box will be much better,
and should exist, but my search program ends in reasonable time just up
to 7x7 s-boxes and grabs some 8x8 s-boxes but not all possible ones. But
I wont go to some forum like reddit/crypto proclaming I've found an
awesome post-quantum algorithm. No way, at least for now.
Cheers
Daniel
> On 4/19/2020 6:15 AM, Daniel wrote:
>> El 19/4/20 a les 0:59, Chris M. Thomasson ha escrit:
>>> On 4/18/2020 4:55 AM, Daniel wrote:
>>>> El 17/4/20 a les 12:13, tranng...@gmail.com ha escrit:
>>>>> On Monday, March 30, 2020 at 11:04:21 PM UTC+7, Daniel wrote:
>>>>>> Hi, folks, this is my last public-key invention. Let's define it:
>>>>>>
>> <snip>
>>>
>>> Sorry for the stupid question: Is this key the result of the shared
>>> secret after asymmetric key exchange? This generated key and the
>>> ciphertext can be known because its hard to get at the original
>>> asymmetric exchange? Is it safe to integrate asymmetric and symmetric
>>> encryption?
>>>
>>> [...]
>>
>> The answer: NO! But thanks to ask. Public key, or asymmetric, is an
>> ambiguous term, unlike symmetric. Can refer to actually encrypting
>> something, as in RSA, or just to get a shared secret that can be used
>> in a session using symmetric crypto, as in Diffie-Hellman. My proposal
>> of algorithm just does a Diffie-Hellman, despite my use (or misuse) of
>> the terms plaintext and ciphertext. Also a digital signature is proposed.
>
> Ahhhh! The word ciphertext confused me. For some damn reason I thought
> you were integrating a symmetric cipher into the mix.
>
No, I'm just using the structure of a symmetric cypher, but's
>> El 19/4/20 a les 0:59, Chris M. Thomasson ha escrit:
>>> On 4/18/2020 4:55 AM, Daniel wrote:
>>>> El 17/4/20 a les 12:13, tranng...@gmail.com ha escrit:
>>>>> On Monday, March 30, 2020 at 11:04:21 PM UTC+7, Daniel wrote:
>>>>>> Hi, folks, this is my last public-key invention. Let's define it:
>>>>>>
>> <snip>
>>>
>>> Sorry for the stupid question: Is this key the result of the shared
>>> secret after asymmetric key exchange? This generated key and the
>>> ciphertext can be known because its hard to get at the original
>>> asymmetric exchange? Is it safe to integrate asymmetric and symmetric
>>> encryption?
>>>
>>> [...]
>>
>> The answer: NO! But thanks to ask. Public key, or asymmetric, is an
>> ambiguous term, unlike symmetric. Can refer to actually encrypting
>> something, as in RSA, or just to get a shared secret that can be used
>> in a session using symmetric crypto, as in Diffie-Hellman. My proposal
>> of algorithm just does a Diffie-Hellman, despite my use (or misuse) of
>> the terms plaintext and ciphertext. Also a digital signature is proposed.
>
> Ahhhh! The word ciphertext confused me. For some damn reason I thought
> you were integrating a symmetric cipher into the mix.
>
asymmetric. I'm experimenting yet.
>
>> So you have a function m(a,b) with complexity and a and b having say
>> 256 bits roughly. I assume to be hard if we get a result r=m(a,b), to
>> recover b knowing only r and a. Hence the terms of symmetric crypto. b
>> in r=m(a,b) plays the role of a key and is secret information. Public
>> information are the algorithm itself and a.
>>
>> To create a shared secret:
>>
>> Both Alice and Bob agree on a public value, let's call it P.
>> Alice chooses a key Ka and sends to Bob Ia=m(P,Ka)
>> Bob does the same so sends to alice Ib=m(P,Kb), where Kb is Bob secret
>> key.
>
> Can Ka and Kb be comprised of arbitrarily sized random bytes?
>
> Say, Alice chooses 301 random bytes for Ka, and Bob decides to use 509
> bytes for Kb?
>
considered reasonable pseudorandom source to generate keys like
/dev/urandom in linux.
>
>> Then Alice computes privately S=m(Ib,m(Ka,P))=m(m(P,Kb),m(Ka,P))
>> Bob at his turn does the same, S=m(Ia,m(Kb,P)=m(m(P,Ka),m(Kb,P))
>>
>> Both S are the same due to the 'restricted commutativity' property
>> that stands that m(m(a,b),m(c,d))=m(m(a,c),m(b,d)).
>> Eve must solve the hard problem above to get both Ka and Kb, which are
>> secret information hold by Alice and Bob.
>>
>> With S you start transmitting information with your favorite symmetric
>> cypher.
>>
>> And why all this: 1 Just pass time, 2 Shor's algorithm can't be
>> applied with the consequences this has, 3 Small in bits signatures
> Okay. Thank you. I remember trying an impl of an earlier version a while
> back. Your algorihtm needs to be studied. Afaict, you are trying to get
> around a quantum-based attack that DH can theoretically fall to?
>
improve it in some way I can't. Particulary the 7x7 s-box, thought I
think is non-trivial is really small. A 31x31 s-box will be much better,
and should exist, but my search program ends in reasonable time just up
to 7x7 s-boxes and grabs some 8x8 s-boxes but not all possible ones. But
I wont go to some forum like reddit/crypto proclaming I've found an
awesome post-quantum algorithm. No way, at least for now.
Cheers
Daniel
Pubkeybreaker
Apr 20, 2020, 6:30:39 PM4/20/20
to
On Monday, April 20, 2020 at 10:38:28 AM UTC-4, Rich wrote:
> Chris M. Thomasson <chris.m.t...@gmail.com> wrote:
> > On 4/19/2020 12:04 PM, Rich wrote:
> >> Chris M. Thomasson <chris.m.t...@gmail.com> wrote:
>
> Ok, assumptions: Identical derivation of secret key, so it is equally
> secure either way.
>
> Secret meeting method: Nothing is transmitted over a transmission
> system, so an Eve can't intercept anything in transmission.
>
> But, Eve could bug the room, and thereby obtain the secret key via that
> method.
>
> Key exchange: something is transmitted, hopefully something that is too
> hard for Eve to decode, so that it does not matter if Eve intercepts or
> not.
Your imagination seems limited.
> Chris M. Thomasson <chris.m.t...@gmail.com> wrote:
> > On 4/19/2020 12:04 PM, Rich wrote:
> >> Chris M. Thomasson <chris.m.t...@gmail.com> wrote:
>
> Ok, assumptions: Identical derivation of secret key, so it is equally
> secure either way.
>
> Secret meeting method: Nothing is transmitted over a transmission
> system, so an Eve can't intercept anything in transmission.
>
> But, Eve could bug the room, and thereby obtain the secret key via that
> method.
>
> Key exchange: something is transmitted, hopefully something that is too
> hard for Eve to decode, so that it does not matter if Eve intercepts or
> not.
Eve kidnaps the courier and forces him/her to reveal it
via rubber hose/threat against family/drugs/bribery/other.
Bandwidth is low and latency extremely high.
> However, method 2 do not require Alice and Bob to be required to
> transport themselves to the same room, which can be a huge benefit
If they use a courier (trusted third party) see above.
Definition: Trust. The condition necessary for betrayal.
Rich
Apr 20, 2020, 7:00:09 PM4/20/20
to
Pubkeybreaker <pubkey...@aol.com> wrote:
> On Monday, April 20, 2020 at 10:38:28 AM UTC-4, Rich wrote:
>> Chris M. Thomasson <chris.m.t...@gmail.com> wrote:
>> > On 4/19/2020 12:04 PM, Rich wrote:
>> >> Chris M. Thomasson <chris.m.t...@gmail.com> wrote:
>
>>
>> Ok, assumptions: Identical derivation of secret key, so it is equally
>> secure either way.
>>
>> Secret meeting method: Nothing is transmitted over a transmission
>> system, so an Eve can't intercept anything in transmission.
>>
>> But, Eve could bug the room, and thereby obtain the secret key via that
>> method.
>>
>> Key exchange: something is transmitted, hopefully something that is too
>> hard for Eve to decode, so that it does not matter if Eve intercepts or
>> not.
>
> Your imagination seems limited.
>
> Eve kidnaps the courier and forces him/her to reveal it
> via rubber hose/threat against family/drugs/bribery/other.
>
> Bandwidth is low and latency extremely high.
That is a fair critique, for an AOB courier mediated exchange. But I
> On Monday, April 20, 2020 at 10:38:28 AM UTC-4, Rich wrote:
>> Chris M. Thomasson <chris.m.t...@gmail.com> wrote:
>> > On 4/19/2020 12:04 PM, Rich wrote:
>> >> Chris M. Thomasson <chris.m.t...@gmail.com> wrote:
>
>>
>> Ok, assumptions: Identical derivation of secret key, so it is equally
>> secure either way.
>>
>> Secret meeting method: Nothing is transmitted over a transmission
>> system, so an Eve can't intercept anything in transmission.
>>
>> But, Eve could bug the room, and thereby obtain the secret key via that
>> method.
>>
>> Key exchange: something is transmitted, hopefully something that is too
>> hard for Eve to decode, so that it does not matter if Eve intercepts or
>> not.
>
> Your imagination seems limited.
>
> Eve kidnaps the courier and forces him/her to reveal it
> via rubber hose/threat against family/drugs/bribery/other.
>
> Bandwidth is low and latency extremely high.
believed Chris to be talking about using something like diffie-hellman
key exchange, where neither has to leave their bunkers in London or HK,
and can agree on a common secret key without Eve learning the same
secret key.
>> However, method 2 do not require Alice and Bob to be required to
>> transport themselves to the same room, which can be a huge benefit
>
> Huh? Alice is in London. Bob is in HK. Getting together is problematic.
> If they use a courier (trusted third party) see above.
>
> Definition: Trust. The condition necessary for betrayal.
thought Chris was talking about, as he's not AOB), and the 'benefit'
was that because they used DH (or something like it) they did not need
to leave their respective bunkers (note the "not" in "do *not* require
... to transport themselves).
FromTheRafters
Apr 20, 2020, 7:42:19 PM4/20/20
to
Rich explained :
I thought he was comparing/contrasting the semantic security of the
mutual key derivation idea versus the symmetric encryption idea while
ignoring the key management aspect of the latter.
mutual key derivation idea versus the symmetric encryption idea while
ignoring the key management aspect of the latter.
Rich
Apr 20, 2020, 11:46:52 PM4/20/20
to
> In the secret meeting, no info is transmitted across the wire to
> obtain the shared secret key. This is not the case wrt any
> asymmetric key exchange?
room" method of key exchange ("In the secret meeting") vs. an
algorithm used to perform the change across a communications medium
("This is not the case wrt any asymmetric key exchange" -- where I read
"not" as referring to the "no info is transmitted across the wire"
portion of the first sentence.
But I did not interpret "in the secret meeting" to mean an AOB style
"courier carries key from Alice to Bob" exchange, which *is* vulnerable
to a rubber hose decryption system as pointed out by pubkeybreaker.
Chris M. Thomasson
Apr 21, 2020, 2:16:51 AM4/21/20
to
asymmetric key exchange in private, instead of sending it across the
wire. Wrt DH, Alice's secret integer is unknown to Bob, and vise versa.
However, I think it still can get a rubber hose treatment. Lets say
Alice gets caught and the captor forces her to give up her secret
integer, and the info discussed in the meeting. Then, the captor will be
able to compute the shared secret key, the same one Bob is going to
eventually compute.
Rich
Apr 21, 2020, 9:56:38 AM4/21/20
to
Chris M. Thomasson <chris.m.t...@gmail.com> wrote:
> Basically, performing the public part of any asymmetric key exchange
> in private, instead of sending it across the wire. Wrt DH, Alice's
> secret integer is unknown to Bob, and vise versa. However, I think
> it still can get a rubber hose treatment. Lets say Alice gets caught
> and the captor forces her to give up her secret integer, and the info
> discussed in the meeting.
If rubber hose decryption is applied to Alice, it does not matter if
> Basically, performing the public part of any asymmetric key exchange
> in private, instead of sending it across the wire. Wrt DH, Alice's
> secret integer is unknown to Bob, and vise versa. However, I think
> it still can get a rubber hose treatment. Lets say Alice gets caught
> and the captor forces her to give up her secret integer, and the info
> discussed in the meeting.
Alice used your "meet Bob in Hotel Monaco Room 15" method or used
Diffie-Hellman. After the 'exchange' (either method) Alice has a
secret she has shared with Bob, and rubber hose decryption techniques,
applied to Alice at a later time, can be utilized to cause Alice to
give up that secret.
Daniel
Apr 21, 2020, 12:04:47 PM4/21/20
to
El 21/4/20 a les 15:56, Rich ha escrit:
Interesting conversation. Can a perfect man-in-the-middle in the middle
from the very building of Alice bunker be detected?. I say perfect
because nowadays you can send a video with some key appearing in it and
this is hard to fake for the man-in-the-middle, but suppose he can
control all levels of communication of Alice towards the rest of the
world and fake them, is there a real solution?. I think there isn't.
from the very building of Alice bunker be detected?. I say perfect
because nowadays you can send a video with some key appearing in it and
this is hard to fake for the man-in-the-middle, but suppose he can
control all levels of communication of Alice towards the rest of the
world and fake them, is there a real solution?. I think there isn't.
Rich
Apr 21, 2020, 12:56:33 PM4/21/20
to
"perfect", would be undetectable by either party.
This is why I keep pounding Kerckhoffs's principle [1] at Chris at
every opportunity. One should design one's systems under the
presumption that there *will* be a perfect, undetectable,
man-in-the-middle, a perfect Eve that can intercept *every* single
exchange over the wire, etc. If the system is still secure, even
though the perfect man-in-the-middle, and the perfect Eve, both got
*everything* (other than the key), then things are good.
But the moment one goes down the road that Chris so often travels, that
of trying to "hide" something from Eve, one runs into problems because
one is no longer designing under the presumption that there *will* be
an Eve and that Eve *will* know *everything* other than the key. And
down that road lies all kinds of hidden security breaks.
[1] https://en.wikipedia.org/wiki/Kerckhoffs%27s_principle (although
Chris seems quite resistant to actually understanding this
principle)
tranng...@gmail.com
Apr 22, 2020, 1:31:00 PM4/22/20
to
On Sat, Apr 18, 2020 at 6:55 PM Daniel wrote:
> El 17/4/20 a les 12:13, tranngocduong at gmail dot com ha escrit:
>
Aha, sequentially. I thought f() applies to all characters of the state
string _in parallel_. Thank you for clarification.
The f() is _crucial_ for security. Let me take a concrete example of
the choice of f that is potentially insecure regardless of number
of rounds. The example is a generalized version of your example in the ducumentation.
f(x, y) = a*x + b*y
where x, y are elements of a [finite] small abelian group (G,+) and a, b are
integers, a != b, and a*x stands for x + x + x +....+ x (a times of x).
The f function is not associative or commutative and is 'restrictively commutative' (hope that's the correct English grammar). Thus it is a legitimate candidate for the present public-key construction. Despite that, as G is small we're able to compute logarithm of every symbol of the output string of mix() and construct a system of linear congruential equations over integers, which is easily solvable.
> El 17/4/20 a les 12:13, tranngocduong at gmail dot com ha escrit:
>
> >
> > 3) The round function mixes the state string (R) with a permuted version
> of the string (R permuted). The specific permutation is string rotation.
> Does the 'restrict commutativity' property still hold if the rotation is
> replaced with another permutation, e.g. decimation?
> Well, it's not exactly string rotation. In this case the m (mixing)
> function will not be reversible knowing the ciphertext and the key. The
> mixing applies f (the 7x7 substitution table) sequentially to adjacent
> elements in the string, while trying to accumulate diffusion. So, if s
> is the state, the process is:
>
> N=length(s)
>
> s[0]=f(s[0],s[-1]) // s[-1]=s[length(s)-1]
> s[1]=f(s[1],s[0])
> s[2]=f(s[2],s[1])
> ...
> and so on, wrapping at the end.
>
> Another permutations are possible but always updating i.e. doing
> s[a]=f(s[a],s[b]). I've not written a formal proof but my experiments
> points to this.
> ...
> >
> > 3) The round function mixes the state string (R) with a permuted version
> of the string (R permuted). The specific permutation is string rotation.
> Does the 'restrict commutativity' property still hold if the rotation is
> replaced with another permutation, e.g. decimation?
> Well, it's not exactly string rotation. In this case the m (mixing)
> function will not be reversible knowing the ciphertext and the key. The
> mixing applies f (the 7x7 substitution table) sequentially to adjacent
> elements in the string, while trying to accumulate diffusion. So, if s
> is the state, the process is:
>
> N=length(s)
>
> s[0]=f(s[0],s[-1]) // s[-1]=s[length(s)-1]
> s[1]=f(s[1],s[0])
> s[2]=f(s[2],s[1])
> ...
> and so on, wrapping at the end.
>
> Another permutations are possible but always updating i.e. doing
> s[a]=f(s[a],s[b]). I've not written a formal proof but my experiments
> points to this.
>
Aha, sequentially. I thought f() applies to all characters of the state
string _in parallel_. Thank you for clarification.
The f() is _crucial_ for security. Let me take a concrete example of
the choice of f that is potentially insecure regardless of number
of rounds. The example is a generalized version of your example in the ducumentation.
f(x, y) = a*x + b*y
where x, y are elements of a [finite] small abelian group (G,+) and a, b are
integers, a != b, and a*x stands for x + x + x +....+ x (a times of x).
The f function is not associative or commutative and is 'restrictively commutative' (hope that's the correct English grammar). Thus it is a legitimate candidate for the present public-key construction. Despite that, as G is small we're able to compute logarithm of every symbol of the output string of mix() and construct a system of linear congruential equations over integers, which is easily solvable.
Daniel
Apr 24, 2020, 7:57:06 AM4/24/20
to
El 22/4/20 a les 19:30, tranng...@gmail.com ha escrit:
I can only agree with you. Perhaps I should make this more explicit in
the documentation, it's exactly the hard problem I use, this not
happening. Restricted commutativity is a requirement, but not enougth.
I'm working (well thinking) in how to make a bigger s-table, as only one
can be used. A single f function.
Cheers
Daniel
the documentation, it's exactly the hard problem I use, this not
happening. Restricted commutativity is a requirement, but not enougth.
I'm working (well thinking) in how to make a bigger s-table, as only one
can be used. A single f function.
Cheers
Daniel
0 new messages