Part 1A: Securing an even more secure connection ...

Gang,

After thinking about the dialog with John and Dave yesterday, I 
have an much improved design. Dave's observation that the first 
scheme I had was "Not Forward Secure" was the main catalyst. 
"Not Forward Secure" means that a government agency could record 
traffic, then legally force GRC to divulge the GRC VoIP private 
key -- then decode ANY of the previous interchanges recorded in 
the past.  This improved approach not only adds full forward 
security, it even eliminates one of the three interchange 
packets, dropping the handshake to just two packets!  <g>

Oh! ... and the new approach does something else that's even 
more cool:  NO conversations can be decoded -- EVER -- before
or EVEN AFTER GRC were to lose control of the master VoIP key!
So any governmental agency that wants our key is welcome to have 
it.  No fight from me.  It won't do anyone any good!  <g>

THE USER'S CLIENT:

The client that wishes to establish a secure, eavesdropper and 
man-in-the-middle proof connection to GRC does several things: 

(1) As before, it generates 64-bytes of pseudo random data to
    be used as half of the material for a secret key.

(2) It uses GRC's well-known built-in public key to encrypt
    the 64-bytes of data.

(3) It creates a one-time-use transient asymmetric key pair.

(4) It then sends one packet to the GRC server containing the
    64-bytes of encrypted data and one of the two asymmetric
    keys.

THE GRC SERVER:

The server receives the clients request packet for a secure, 
eavesdropper and man-in-the-middle proof connection. It does 
several things:

(1) As before, it generates 64-bytes of pseudo random data to
    be used as half of the material for a secret key.

(2) But this time it encrypts the 64-bytes with the public
    key sent to it by the client.

(3) It decrpyts the 64-bytes of data sent to it by the client
    using its private key.

(4) It sends one packet containing its 64-bytes of random data,
    encrypted with the client's public key, to the client.

THE USER'S CLIENT:

Upon receiving the server's reply, the client uses its other 
asymmetric key to decrypt the server's 64-bytes of random 
session data.  Now the client has the 64-bytes that it 
generated, plus the 64-bytes that the server sent.  So, as 
before, it dual hashes them into a single 128-bit secret master 
session key, which is uses for the duration of the conversation.

THE GRC SERVER:

The GRC server has the client's decrypted 64-bytes of random 
session data, and the 64-bytes that it generated.  So, as before 
and just like the client, it dual hashes them into a single 128-
bit secret master session key, which is uses for the duration of 
the conversation.

Now both endpoints have the identical 128-bit master session 
key, so they switch to using it.  And that's it!

>---------------------------------------------------------------

Protocol Analysis:

As before, since no eavesdropper is able to decrypt the 64-bytes 
of pseudo random data generated by the client and encrypted with 
the server's public key, there is no way for anyone to determine 
the client's half of the payload used to create the master 
session key.

This time, however, there is also no way for anyone other than 
the client to decrypt the server's 64 pseudo random bytes which 
were encrypted using the client's temporary asymmetric key and 
sent to the client.  Before, the server was sending its 64-bytes 
in the clear, but no longer.

Also, John Graham-Cumming's concerns about any possible 
plaintext or ciphertext exploits never arise since the client is 
no longer encrypting data sent to it by the server -- it is ONLY 
encrypting its own pseudo randomly generated data.

Passive Eavesdropping:

No passive eavesdropper can decrypt EITHER of the 64-byte blocks 
moving past it this time.  BOTH are encrypted by each side's 
freely available public asymmetric key -- GRC's is built into 
every client, and the client's was openly sent to the server -- 
but both blocks of random data can only be decrypted by their 
secret private keys.  So any passive eavesdropped is out of 
luck.

And here's the cool part: Even if some agency like a government 
were to force GRC to release its private key, this would only 
allow that agency to decrypt 64 of the 128 bytes used to 
subsequently form the secret master session key ... which is 
totally useless to anyone.  Having only half of the random data 
is totally useless.  ONLY the client is able to decrypt the 64 
bytes of random data sent to it by the server, since only it 
knows the matching asymmetric private key that it created on-
the-fly only for the purpose of exchanging the initial pseudo-
random data with the server.

The Man In The Middle:

The man in the middle case is now a bit more interesting.  With 
this second approach, the typical man-in-the-middle has even 
less information to work with, since both sets of 64-byte data 
passing by are encrypted (although he already had much too 
little).

However, IF GRC were to lose control of our private asymmetric 
key, then a man in the middle could successfully impersonate us 
to breach the security of the system.  But that's what it would 
take to compromise the system's security:  (1) Active 
interception and custom on-the-fly modification of the packet 
traffic, (2) having access to GRC's private asymmetric key, and 
(3) GRC still being willing to offer client negotiation services 
after having lost control of our private key.  <g>

Note also, that this is another GOOD REASON for us NOT following 
any existing arbitrary standards -- such as SIP -- since 
accomplishing an active traffic modification interception would 
also require the custom reverse-engineering of all of my 
proprietary protocols -- not just client-to-GRC but also client-
to-client, where the actual conversations occur.  And I *don't* 
give out my source code.

So with this second-generation approach we solve the problem of 
"forward security", getting "perfect forward security", and 
we're hardened against almost any conceivable security breach.

I think we've this does it.  :)

>---------------------------------------------------------------

The client-to-client protocol:

The inter-client conversation, where VoIP actually occurs, will 
be similarly super-secure and offer perfect forward security as 
follows:

After each client separately connects to GRC with a tamper-proof 
channel, we'll authenticate them with their current set of 
online "identities".  We'll look up all of the other-party 
identities that each client knows, and present each with their 
"friends" who are currently online.  One will choose another, 
and the connection startup begins.

A single 128-bit secure random symmetric key will be issued to 
both clients who have agreed to talk to each other and NAT 
traversal will be achieved so that they can exchange traffic 
directly.  Using that initial 128-bit shared secret key issued 
by GRC to establish an initial secure channel, they will each 
immediately generate a transient asymmetric key-pair and send 
each other a public key.  Each will then generate 64-bytes of 
pseudo random data, encrpyt it with the other's public key, and 
send that data over to the other.  Each then decrpyts the 
other's 64-bytes, has all 128 bytes for the hashing which forms 
their new private 128-bit shared secret session key ... which 
they then switch to.

You'll notice that this nicely reuses all of the logic and code 
that we already have in place for the GRC connection setup, and 
it gives the two direct conversing clients their own secrecy 
from GRC and perfect forward secrecy so that no one recording 
the traffic can EVER decrypt it.

-- 
________________________________________________________________
Steve.
0
Steve
11/12/2005 7:16:25 PM
grc.thinktank 696 articles. 0 followers. Follow

41 Replies
990 Views

Similar Articles

[PageSpeed] 12
Get it on Google Play
Get it on Apple App Store

Steve,

Yep, that pretty much covers my concerns.  Nothing's being sent in the 
clear now.

Have you decided on the asymmetric algorithm you are going to use?

John.
0
John
11/12/2005 7:39:04 PM
[for the unabridged version, see John Graham-Cumming's post 
above]

> Yep, that pretty much covers my concerns.
> Nothing's being sent in the clear now.

:)


> Have you decided on the asymmetric algorithm you are going to use?

For dealing with all of the stupid nightmare (and rather opaque) 
crypto export issues, I *love* the idea of not needing to 
incorporate *ANY* crypto into iSpeaq at all.  I've been doing a 
bit of preliminary research into Windows' existing crypto API, 
and it looks like it will do everything I need.  <g>

-- 
________________________________________________________________
Steve.
0
Steve
11/12/2005 8:09:48 PM
Steve Gibson wrote:

> 
> (1) As before, it generates 64-bytes of pseudo random data to
>     be used as half of the material for a secret key.
> 

You haven;'t indicated whether you are going to generate your own random 
data, or use a Windows function to do so. However, one system that I was 
involved with used ("the number of CPU ticks since last reboot" mod n) to 
generate random numbers. Given today's clock speeds of several GHz that is 
fairly unpredictable!

Just a thought.

AlanD
0
AlanD
11/12/2005 9:23:39 PM
Steve Gibson wrote:
[...]
> And here's the cool part: Even if some agency like a government
> were to force GRC to release its private key, this would only
> allow that agency to decrypt 64 of the 128 bytes used to
> subsequently form the secret master session key ... which is
> totally useless to anyone.  Having only half of the random data
> is totally useless.  ONLY the client is able to decrypt the 64
> bytes of random data sent to it by the server, since only it
> knows the matching asymmetric private key that it created on-
> the-fly only for the purpose of exchanging the initial pseudo-
> random data with the server.
[...]

64-bits seems like a fairly small margin of security if GRC is compromised
in some way. At 1,000,000,000 attempts a second, that's only 584 years of
security. Why not exchange 128 bytes of random data in each packet, so at
worst, 128 bits needs to be successfully generated by an attacker?

Regards,
Sam
0
Sam
11/12/2005 11:18:13 PM
Steve Gibson wrote:

> Note also, that this is another GOOD REASON for us NOT following 
> any existing arbitrary standards -- such as SIP -- since 
> accomplishing an active traffic modification interception would 
> also require the custom reverse-engineering of all of my 
> proprietary protocols -- not just client-to-GRC but also client-
> to-client, where the actual conversations occur.  And I *don't* 
> give out my source code.

Sorry if you have already discussed this, but wouldn't the government 
also be able to force you into writing a backdoor into your program?

If people cannot see your code, they cannot be totally sure that you're 
not collaborating with the CIA.

Yes, I know it's highly unlikely that the government will force you to 
do something like that, but there's certainly a possibility.

Perhaps you could use some sort of "signal" in this newsgroups to alert 
us discreetly in case that the guys in black suits pay a visit to you ;)

Regards.
0
Leolo
11/12/2005 11:22:12 PM
On Sun, 13 Nov 2005 00:22:12, Leolo wrote:

>Sorry if you have already discussed this, but wouldn't the government 
>also be able to force you into writing a backdoor into your program?

While Steve can answer 'No' to the question "Has an Agency asked for a 
backdoor?", all is well.  Be worried when the response is "I couldn't 
possibly comment".

A sensible question to ask now and then, of course, as some folk do for 
the UK ISPs.  So far the answer has been a resounding "No!". :)

-- 
Jim Crowther                   "It's MY computer" (tm SMG)

Always learning.

0
Jim
11/13/2005 12:52:04 AM
Jim Crowther wrote:

> A sensible question to ask now and then, of course, as some folk do for 
> the UK ISPs.  So far the answer has been a resounding "No!". :)
> 

Hear, hear ... the thing then is to periodically pose that question to 
Steve at least on an annual basis.

So, Steve, "Has an Agency asked for a backdoor?" ... Huh?
-- 
Louis "the lip" Bone

0
Louis
11/13/2005 2:11:14 AM
Steve Gibson wrote:
[...]
> You'll notice that this nicely reuses all of the logic and code
> that we already have in place for the GRC connection setup, and
> it gives the two direct conversing clients their own secrecy
> from GRC and perfect forward secrecy so that no one recording
> the traffic can EVER decrypt it.

The only thing missing, as far as I can see, is a provision for
detecting/preventing the unlikely case that the GRC server is compromised
(perhaps via court-order) in a way that allows interception and
modification of the GRC-generated p2p session-establishment key or
GRC-originated peer negotiations.

Once I've connected to, and verified, a peer, I shouldn't have to manually
verify the peer again, and I should never have to worry about the
possibility that GRC has been subverted and is connecting me to another
peer instead.

If GRC can be induced to connect Alice and Bob to Eve, then Eve would be in
a position to perform a MITM. This can't be prevented when Alice and Bob
don't know anything about eachother, but if Alice and Bob have connected to
eachother in the past, it should be possible to securely exchange
information that identifies Alice and Bob (optionally, perhaps -- Alice or
Bob may wish to be deniably anonymous).

ISTM that if Alice and Bob are both generating public and private keys (a
time-consuming process) for connection build-up, these keys could be kept
around and used for some very basic end-point authentication. You'd know if
your friend's private key has changed because you've kept their public key.
For someone wanting a one-off and completely unidentifiable (yet still
encrypted) connection, an option to discard both keypairs would be
possible.

The only problem I see with keeping keypairs is that under the current
key-exchange plans, there would be keys kept around that could possibly
break Perfect Forward Secrecy (though both endpoints would need to be
compromised).

Regards,
Sam
0
Sam
11/13/2005 2:25:12 AM
On Sun, 13 Nov 2005 00:22:12 +0100, Leolo wrote:

> wouldn't the government also be able to force you into writing a backdoor
> into your program?

I am personally convinced that Steve would abandon the project altogether
rather than succumb to such pressure.

HT
0
Horseradish
11/13/2005 10:28:34 AM
Steve Gibson wrote:
> Note also, that this is another GOOD REASON for us NOT following 
> any existing arbitrary standards -- such as SIP -- since 
> accomplishing an active traffic modification interception would 
> also require the custom reverse-engineering of all of my 
> proprietary protocols -- not just client-to-GRC but also client-
> to-client, where the actual conversations occur.  And I *don't* 
> give out my source code.
  Largely irrelevent. if you don't document your protocols or issue your source,
nobody in the crypto world will touch it with a barge pole - and even if you
issue the protocol specs, they will still distrust that your implimentation is
secure
  Besides, we both know how easy it is to decompile the output of the major
compilers, and/or simply hack/single step the binaries to reverse-engineer the
protocols involved. if you hand a determined hacker the binaries, you might as
well hand them a copy of the source and at least have them appreciate how well
you documented it :)

  Leaving behind a documented standard is always a hard choice and one not to be
taken lightly. Skype is likely to go the way of the betamax recorder RSN, as
soon as the nat traversal issues of udp based SIP are worked out - and to be
honest, as soon as decent encryption is added to SIP by at least one major
vendor (and google have promised to so add it) I will drop almost anything else
like a hot brick.
0
Dave
11/13/2005 12:38:24 PM
Sam Schinke wrote:
> Steve Gibson wrote:
> [...]
> 
>>allow that agency to decrypt 64 of the 128 bytes used to
> 
> 64-bits seems like a fairly small margin of security if GRC is compromised
> in some way. At 1,000,000,000 attempts a second, that's only 584 years of
> security. Why not exchange 128 bytes of random data in each packet, so at
> worst, 128 bits needs to be successfully generated by an attacker?
> 

I believe it's 64 *bytes* not bits that Steve plans on exchanging ;)
0
sparky
11/13/2005 1:52:08 PM
Dave Howe wrote:
>   Besides, we both know how easy it is to decompile the output of the major
> compilers, and/or simply hack/single step the binaries to reverse-engineer the
> protocols involved. if you hand a determined hacker the binaries, you might as
> well hand them a copy of the source and at least have them appreciate how well
> you documented it :)

Given that Steve does everything in assembler there's no need to 
decompile, a disassembler will show you everything you need to know.

John.
0
John
11/13/2005 7:17:41 PM
sparky wrote:

> Sam Schinke wrote:
>> Steve Gibson wrote:
>> [...]
>> 
>>>allow that agency to decrypt 64 of the 128 bytes used to
>> 
>> 64-bits seems like a fairly small margin of security if GRC is
>> compromised in some way. At 1,000,000,000 attempts a second, that's only
>> 584 years of security. Why not exchange 128 bytes of random data in each
>> packet, so at worst, 128 bits needs to be successfully generated by an
>> attacker?
>> 
> 
> I believe it's 64 *bytes* not bits that Steve plans on exchanging ;)

Ah, that's a fair chunk more!

Regards,
Sam
0
Sam
11/13/2005 9:12:04 PM
[for the unabridged version, see AlanD's post above]

> You haven;'t indicated whether you are going to generate your
> own random data, or use a Windows function to do so. However,
> one system that I was involved with used ("the number of CPU
> ticks since last reboot" mod n) to generate random numbers.
> Given today's clock speeds of several GHz that is fairly
> unpredictable!
> 
> Just a thought.

If I generate my own pseudo-random data I'll see the generator 
with all sorts of unique stuff ... and the output from the clock 
cycle counter (Intel's RDTSC instruction -- Read Time Stamp 
Counter) will definitely be among them.  :)

-- 
________________________________________________________________
Steve.
0
Steve
11/13/2005 10:05:23 PM
[for the unabridged version, see Sam Schinke's post above]

> 64-bits seems like a fairly small margin of security if GRC
> is compromised in some way. At 1,000,000,000 attempts a second,
> that's only 584 years of security. Why not exchange 128 bytes
> of random data in each packet, so at worst, 128 bits needs to
> be successfully generated by an attacker?

Nowhere is the system is the security any lower than 128-bits.

Each side's 64 BYTES of data (512-bits) is assembled into a 
single 128 byte composite message which is then dual hashed down 
to a 128-bit digest, which is used as shared secret symmetric 
keys.  So it should all be super-safe from any sorts of brute 
force attacks.

To the best of my knowledge -- and I have recently updated 
myself -- 128 bits is currently regarded as a really extremely 
strong symmetric key length for contemporary block ciphers.

-- 
________________________________________________________________
Steve.
0
Steve
11/13/2005 10:09:05 PM
[for the unabridged version, see "Louis \"the lip\" Bone" 
<lwbone@earthlink.net>'s post above]

> So, Steve, "Has an Agency asked for a backdoor?" ... Huh?

No.

And I would never willingly offer a knowingly security-
compromised service. I doubt that I could be compelled to 
continue offering a service against my will. So if I ever 
suddenly discontinue the offering, that would be the useful 
clue.

-- 
________________________________________________________________
Steve.
0
Steve
11/13/2005 10:13:25 PM
[for the unabridged version, see Leolo's post above]

> Sorry if you have already discussed this, but wouldn't the
> government also be able to force you into writing a backdoor
> into your program?

No way.  I would simply kill the product offering completely.


> If people cannot see your code, they cannot be totally sure
> that you're not collaborating with the CIA.

Remember that the system WILL also support GRC-free direct
peer-to-peer operation using a pre-shared key and dynamic 
asymmetric crypto tunnel re-keying to offer perfect forward 
security.  So anyone who doesn't trust me can still use the 
system in a less automatic mode ... with no possibility, under 
ANY conceivable scenario, of security being breached.

And ... it seems to me that GRC will represent a far smaller 
"target" for governmental interference than the likes of Skype, 
Google, etc.


> Yes, I know it's highly unlikely that the government will
> force you to do something like that, but there's certainly
> a possibility.

Indeed, anything is, by definition, possible.  But me, who I am, 
what I stand for, the technology of my code, and how and what it 
was designed to do, are *ALL* vasty more transparent than other 
well-known VoIP systems.

Take your pick.  :)

-- 
________________________________________________________________
Steve.
0
Steve
11/13/2005 10:40:07 PM
[for the unabridged version, see Horseradish Tree's post above]

> I am personally convinced that Steve would abandon the
> project altogether rather than succumb to such pressure.

Precisely.  That seems the simple and easy answer.  I would 
simply stop offering something that I was no longer able to 
represent as secure.

-- 
________________________________________________________________
Steve.
0
Steve
11/13/2005 10:40:57 PM
[for the unabridged version, see Sam Schinke's post above]

Does it help that anyone who was concerned about all that could 
simply checkout the IP addresses to which their packets were 
being sent?  At NO POINT will I be offering any proxying for 
two-party conferences, unlike Skype and GoogleTalk which do.

And the client app could easily display -- under something like 
"connection property details" -- both the public local IP and 
port and the remote IP and port for the endpoints.  Thus the 
users could verbally verify with each other that their traffic 
is aimed directly at each other.

-- 
________________________________________________________________
Steve.
0
Steve
11/13/2005 10:47:28 PM
In article <MPG.1de16257a586bed048c@4.79.142.203>, Steve Gibson writes
>[for the unabridged version, see Sam Schinke's post above]
>
>Does it help that anyone who was concerned about all that could
>simply checkout the IP addresses to which their packets were
>being sent?  At NO POINT will I be offering any proxying for
>two-party conferences, unlike Skype and GoogleTalk which do.
>
>And the client app could easily display -- under something like
>"connection property details" -- both the public local IP and
>port and the remote IP and port for the endpoints.  Thus the
>users could verbally verify with each other that their traffic
>is aimed directly at each other.

Featuritis warning. :-)

Would it be worth it/feasible to display it in the status bar or on the 
toolbar?

-- 
GRC Newsgroups/Guidelines/No Regrets:
http://www.imilly.com/noregrets.htm
 From invalid, Reply To works.
Kevin A.
0
Kevin
11/14/2005 1:10:55 AM
[for the unabridged version, see Kevin A.'s post above]

> Would it be worth it/feasible to display it in the status
> bar or on the toolbar?

I think it's the sort of thing that should generally be hidden, 
but available to anyone who wanted to know for whatever reason.

-- 
________________________________________________________________
Steve.
0
Steve
11/14/2005 2:30:33 AM
Steve Gibson wrote:

> [for the unabridged version, see Sam Schinke's post above]
> 
> Does it help that anyone who was concerned about all that could
> simply checkout the IP addresses to which their packets were
> being sent?  At NO POINT will I be offering any proxying for
> two-party conferences, unlike Skype and GoogleTalk which do.
> 
> And the client app could easily display -- under something like
> "connection property details" -- both the public local IP and
> port and the remote IP and port for the endpoints.  Thus the
> users could verbally verify with each other that their traffic
> is aimed directly at each other.

That is minimal assistance if passive packet modification is also possible,
I think. If the key GRC provides for two clients to use to build up their
session is compromised, and neither client has the other's public key in
advance, MITM within that initial connection is possible, right? Or does
GRC also send the clients each-other's pre-generated key?

Regards,
Sam
0
Sam
11/14/2005 3:43:20 AM
[for the unabridged version, see Sam Schinke's post above]

> That is minimal assistance if passive packet modification is
> also possible, I think.

Absolutely right Sam.


> If the key GRC provides for two clients to use to build up
> their session is compromised, and neither client has the
> other's public key in advance, MITM within that initial
> connection is possible, right?

Right.


> Or does GRC also send the clients each-other's pre-generated key?

That wouldn't help anyway, right?  If we're going to assume that 
GRC has sacrificed its private key, so that a MITM attack in the 
client-to-GRC link is possible, then GRC could be impersonated 
and the clients could be given specific keys to use.

The only way I can see to solve that situation would be to 
statically pre-assign clients asymmetric key pairs and have them 
authenticate their respective identities against each other 
directly.  Any use of GRC would have to be suspect if we're 
pushing this scenario all the way to the end.

-- 
________________________________________________________________
Steve.
0
Steve
11/14/2005 5:00:28 AM
[For the unexcerpted original, see above]
Steve Gibson wrote ...

> The only way I can see to solve that situation would be to 
> statically pre-assign clients asymmetric key pairs and have them 
> authenticate their respective identities against each other 
> directly.  Any use of GRC would have to be suspect if we're 
> pushing this scenario all the way to the end.

Does that mean that each time the iSpeaq client is downloaded, 
presumedly over an SSL/https connection to GRC, a new asymmetric key 
pair is embedded?

I may be completely misunderstanding this, but it seems to me that if 
each copy of the iSpeaq client is unique and only known to GRC that a 
MITM wouldn't be able to impersonate GRC without knowing the clients' 
unique keys or whatever.

-- 

Terry //
0
Terry
11/14/2005 6:04:13 AM
Steve Gibson wrote:
[...]
> The only way I can see to solve that situation would be to
> statically pre-assign clients asymmetric key pairs and have them
> authenticate their respective identities against each other
> directly. 

A few possibilities that I see:

1) Allow users to persist their asymmetric key pairs. So long as one user
has kept their private key, and it has been verified out-of-band, a secure
endpoint-verified connection can be assumed (at least on the part of the
party who _hasn't_ kept their private key). Persistence could be on the GRC
server, so long as the actual data was encrypted with something only
available to the client.

The only problem here is that if both parties are compromised down the road,
Perfect Forward Secrecy of packet data is lost.

2) Figure out an unspoofable cryptographic method to verify the user tokens
we were discussing earlier. Since they are valuable, clearly they can't
change hands, but that doesn't mean there is NO information
available/obtainable from them, right? Exchanging this type of information
almost presupposes a way to produce verifiable signatures, though. *grrr*

3) Persist one or more assymetric keys for each endpoint, but never use them
for encryption. These would be (optional) signing and verification keys.
Once a connection is established, an in-band exchange can make sure the
same signing key is at the other end as the last time.

I think this is the most promising, and does nothing to Perfect Forward
Secrecy.

> Any use of GRC would have to be suspect if we're 
> pushing this scenario all the way to the end.

The way I see it, in order to be fully credible, a compromise of GRC has to
be a near zero-value goal in the first place. Everything should be designed
so that even if GRC is compromised there is _still_ a way to detect any
GRC-originated tampering (provided the users do their due dilligence, which
_should_ be made fairly easy).

The best an attacker should be able to hope for is to remove the convenience
that using GRC as an intermediary provides.

Another option, that I find intriguing, would be to provide a "GRC-VoIP
Intermediary Server" that can be configured with a key and "drop" client
executables. This can remove the question of GRC's security entirely from
the equation. If servers implementing your intermediary and registration
logic show up all over the place, who's to say that all, or even most, use
of this program will even go through GRC?

Regards,
Sam
0
Sam
11/14/2005 7:17:03 AM
Terry L. Webb wrote:

> [For the unexcerpted original, see above]
> Steve Gibson wrote ...
> 
>> The only way I can see to solve that situation would be to
>> statically pre-assign clients asymmetric key pairs and have them
>> authenticate their respective identities against each other
>> directly.  Any use of GRC would have to be suspect if we're
>> pushing this scenario all the way to the end.
> 
> Does that mean that each time the iSpeaq client is downloaded,
> presumedly over an SSL/https connection to GRC, a new asymmetric key
> pair is embedded?
> 
> I may be completely misunderstanding this, but it seems to me that if
> each copy of the iSpeaq client is unique and only known to GRC that a
> MITM wouldn't be able to impersonate GRC without knowing the clients'
> unique keys or whatever.

The down-side of this is that each iSpeaq binary would also be uniquely
identifiable to any malicious or overly-nosy parties.

But your point that double-ended verified connections to GRC become possible
is valid. The first connection packet would need to contain the key
identifier and then provide a signature of some of the encrypted key
material (though replay is a concern, no?). This could function as somewhat
of a "login" to GRC's connection broker.

Regards,
Sam
0
Sam
11/14/2005 7:20:56 AM
> For dealing with all of the stupid nightmare (and rather opaque)
> crypto export issues, I *love* the idea of not needing to
> incorporate *ANY* crypto into iSpeaq at all.  I've been doing a
> bit of preliminary research into Windows' existing crypto API,
> and it looks like it will do everything I need.  <g>

Not a bad idea, although, another approach may be having the
program download the "ready to run" OpenSSL binaries from the
'net (e.g. http://www.slproweb.com/products/Win32OpenSSL.html)
this way you won't incorporate any "crypto stuff" inside the program
and won't have legal issues ;-)



0
ObiWan
11/14/2005 8:15:06 AM
[For the unexcerpted original, see above]
Sam Schinke wrote ...

> > I may be completely misunderstanding this, but it seems to me that if
> > each copy of the iSpeaq client is unique and only known to GRC that a
> > MITM wouldn't be able to impersonate GRC without knowing the clients'
> > unique keys or whatever.
> 
> The down-side of this is that each iSpeaq binary would also be uniquely
> identifiable to any malicious or overly-nosy parties.

True.  Periodically "refreshing" your copy of iSpeaq would minimize that 
a bit.

-- 

Terry //
0
Terry
11/14/2005 5:45:40 PM
Steve Gibson wrote:
> [for the unabridged version, see Sam Schinke's post above]

> To the best of my knowledge -- and I have recently updated 
> myself -- 128 bits is currently regarded as a really extremely 
> strong symmetric key length for contemporary block ciphers.

I've been a part of distributed.net's code cracking efforts for several 
*years* now.  we're currently working on a 72-bit RC5 encryption, and 
I've got about 1200 calendar days worth of compute time (across multiple 
CPUs) in it.  Their stats page is down right now, but if I recall [1] 
correctly, they're running at the equivalent of something like 1.1 
million 500+MHz P IIIs of compute power for those 1200 some-odd days, 
and are only a small fraction of the way into brute-forcing the crypto.

I think 128 bits in whatever (non-broken) crypto algorithm should be 
sufficient for the near future! [2]

[1] as I said, the stats server is down right now, so don't quote me on 
these numbers, but they're ballpark accurate.

[2] I am nowhere near a crypto expert, just SWAGing here...  :)

-- 
FreeMan
 From address is legit

The most important point in a man's life is knowing his time when it comes.
0
FreeMan
11/14/2005 6:56:04 PM
[for the unabridged version, see ObiWan's post above]

> > For dealing with all of the stupid nightmare (and rather
> > opaque) crypto export issues, I *love* the idea of not
> > needing to incorporate *ANY* crypto into iSpeaq at all.
> > I've been doing a bit of preliminary research into Windows'
> > existing crypto API, and it looks like it will do everything
> > I need.  <g>
> 
> Not a bad idea, although, another approach may be having the
> program download the "ready to run" OpenSSL binaries from the
> 'net (e.g. http://www.slproweb.com/products/Win32OpenSSL.html)
> this way you won't incorporate any "crypto stuff" inside the
> program and won't have legal issues ;-)

If Windows didn't have sufficient crypto built-in -- as it does 
appear to, albeit with a very annoying API -- I would need to 
come up with another approach. Fortunately it looks like Windows 
will be enough.

I also wonder whether a program that simply downloads a part of 
itself -- even though it's a well-known Open Source library -- 
would get me off of any hooks.  I sorta doubt it.  :(

But the point is moot anyway, since I'm pretty sure I'll be able 
to use Windows.  (Good idea though Obi!)

-- 
________________________________________________________________
Steve.
0
Steve
11/15/2005 4:31:34 AM
<snippage>
> But the point is moot anyway, since I'm pretty sure I'll
> be able  to use Windows.  (Good idea though Obi!)

Thanks Steve, the CryptoAPI isn't bad (ok, somewhat
convoluted <g>) and even allows to use "pluggable
encryption modules" and the like, the good side of that
approach is that you may use whatever ID handler (e.g.
smartcards, biometrics devices and so on) without even
having to change your application (the API will be the
same) this in turn opens up some interesting scenarios;
from writing your own "plugin" to allowing some different
authentication schemes for particular purposes (e.g.
using a couple of smartcards); I just wonder if the iSpeaq
will always have the same set of functionalities from the
CryptoAPI since afaik in some countries the functions are
limited and, although the API calls will be there the calls
won't be working (will be "fake") or will have only limited
functionalities.. btw the application may be able to check
such things but well.. this means extra code :-/

That said (or well.. written) did you think about the idea of
using a portion of the voice stream as a "one time pad" ?

That is, while the initial contact will use the cryptoapi and
all the already described mechanism, once the "talking
parties" will have enough audio data, they may store a
portion of such data locally and use that portion as an
OTP source, this will avoid another "handshake" from
the parties and btw the OTP may be constantly refilled
upon each contact (sure, there may be an option to reset
it and start from scratch if needed), such a thing may also
lower the load on the GRC server side since having an
OTP two parties won'r even need to contact the server
to start a conversation; in such a case, both OTP data
may be stored using whatever local encryption and the
program may ask for a password (upon startup) to
access the OTP data; at that point it would just be a
matter of using an NTP server to determine the current
date/time and use such infos to calculate which "piece"
of OTP to use for that conversation (well, ok, once one
will know with whom he'll be talking.. opening the related
OTP data)



0
ObiWan
11/15/2005 7:53:19 AM
ObiWan wrote:
>>For dealing with all of the stupid nightmare (and rather opaque)
>>crypto export issues, I *love* the idea of not needing to
>>incorporate *ANY* crypto into iSpeaq at all.  I've been doing a
>>bit of preliminary research into Windows' existing crypto API,
>>and it looks like it will do everything I need.  <g>
> 
> 
> Not a bad idea, although, another approach may be having the
> program download the "ready to run" OpenSSL binaries from the
> 'net (e.g. http://www.slproweb.com/products/Win32OpenSSL.html)
> this way you won't incorporate any "crypto stuff" inside the program
> and won't have legal issues ;-)

Would another advantage to OpenSSL include portability? Some of us are 
looking to a Linux-only future.


0
Roger
11/15/2005 5:44:49 PM
Salaam!

ObiWan wrote:

 > <snippage>
 > I just wonder if the iSpeaq will always have the same
 > set of functionalities from the CryptoAPI since afaik
 > in some countries the functions are limited ...

    As I recall ...

    Some years ago there were US government restrictions on the export 
of cryptographic protocols because they are regarded as a munition. 
During that period Microsoft exported Windows versions that had the 
same API as the domestic versions (purported to be 128-bit but 
actually 112-bit), but which generated keys using 64 bits that had 
been provided to (by?) the NSA, thus reducing the export versions to 
56-bit keys that the NSA could readily break.  Later, these export 
restrictions were relaxed, and 128-bit encryption is now exportable ~ 
although anyone proposing to do so had better check to see what the 
current legal landscape looks like.

    At any rate, the functionalities are the same, it's the 
key-generation component that generated crippled keys, and most of 
those operating systems are out the window by now.

    (I was never able to figure out why someone interested in strong 
encryption couldn't just come to America, buy a computer, and take it 
home with them.  Or have a friend buy a domestic version of Windows 
from Walmart and send it to them.  Oh, well, that's government ...)

was-salaam,
abujamal

0
hajj
11/17/2005 10:17:04 AM
[for the unabridged version, see Sam Schinke's post above]

Sam,

Your various ideas are great from a "pushing the boundaries of 
theory" standpoint <<grin>>  but I think we are past the point 
of reasonable solutions to reasonable problems. From the user's 
standpoint, it seems to me that the complexity required to 
mitigate the far fetched theoretical attacks outweighs the risks 
and hugely hurts the application's manageability.

I'm happy with providing the high level of security to users 
that we have worked out, where we have perfect forward security 
and an attack would require (a) the acquisition of GRC's private 
key, and (b) the reverse engineering of my proprietary 
protocols, and (c) the creation of a dynamic interception system 
for those proprietary protocols to create a transparent man-in-
the-middle, and (d) the successful interception and modification 
of the user's VoIP traffic.

That's just so far beyond reasonable that I'm content to explain 
that theoretical vulnerability, state that our private key has 
never been divulged, and tell anyone who still wants MORE 
security that they can pre-share a private key and connect 
directly point-to-point without GRC's involvement for the most 
absolutely perfect security possible, including perfect forward 
security, using today's crypto technology.

-- 
________________________________________________________________
Steve.
0
Steve
11/18/2005 7:12:20 PM
Steve Gibson wrote:
[...]
> That's just so far beyond reasonable that I'm content to explain
> that theoretical vulnerability, state that our private key has
> never been divulged, and tell anyone who still wants MORE
> security that they can pre-share a private key and connect
> directly point-to-point without GRC's involvement for the most
> absolutely perfect security possible, including perfect forward
> security, using today's crypto technology.

Cheers, works for me. If the app supports in-band file-transfer, identities
can be securely confirmed via transfer of PGP-related data. And if not,
in/out-of-band verification is still possible.

Regards,
Sam
0
Sam
11/19/2005 1:40:26 AM
hajj abujamal wrote:
>    At any rate, the functionalities are the same, it's the
> key-generation component that generated crippled keys, and most of those
> operating systems are out the window by now.
Apart from non-domestic pre-XP versions, who will find accounts created before
the "upgrade" to 128 bit EFS still use the old export-quality levels. Oh, and
anyone in a country that the US still doesn't allow export of strong crypto to....
0
Dave
11/20/2005 2:43:17 AM
Salaam!

Dave Howe wrote:

 > hajj abujamal wrote:
 >> At any rate, the functionalities are the same, it's the
 >> key-generation component that generated crippled keys,
 >> and most of those operating systems are out the window by now.

 > Apart from non-domestic pre-XP versions, who will find accounts
 > created before the "upgrade" to 128 bit EFS still use the old
 > export-quality levels. Oh, and anyone in a country that the US
 > still doesn't allow export of strong crypto to ...

    Windows 98SE deployed 128-bit encryption, the first export 
versions had crippled keys.  As for Syria, Iran, North Korea, and the 
other countries to which export of strong encryption is still illegal, 
you can rest assured that they have all purchased domestic versions in 
the United States and replaced the crippled versions in most 
installations, and the 128-bit crippled versions will still work 
anyway with the crippled keys.

was-salaam,
abujamal


0
hajj
11/21/2005 12:06:13 AM
On Sun, 20 Nov 2005 16:06:13, hajj abujamal wrote:

>   Windows 98SE deployed 128-bit encryption, the first export versions 
>had crippled keys.  As for Syria, Iran, North Korea, and the other 
>countries to which export of strong encryption is still illegal, you 
>can rest assured that they have all purchased domestic versions in the 
>United States and replaced the crippled versions in most installations, 
>and the 128-bit crippled versions will still work anyway with the 
>crippled keys.

I'm very glad to have affirmed what I had of course expected. :)

-- 
Jim Crowther.    "Life is not a journey to the grave with the intention of
arriving safely in a well preserved body, but rather to skid in broadside,
thoroughly used up , totally worn out and loudly proclaiming;
WOW!!! What a ride."                           "It's MY computer" (tm SMG)
0
Jim
11/21/2005 2:04:51 AM
Steve Gibson wrote:

> If Windows didn't have sufficient crypto built-in -- as it does 
> appear to, albeit with a very annoying API -- I would need to 
> come up with another approach. Fortunately it looks like Windows 
> will be enough.

Here are some older Facts:
<http://www2.epic.org/reports/crypto2000/>
---------------------------------
Cryptography and Liberty 2000
An International Survey of Encryption Policy
---------------------------------

HTH,
Carsten
0
Carsten
11/21/2005 8:05:42 AM
hajj abujamal wrote:
>    Windows 98SE deployed 128-bit encryption, the first export versions
> had crippled keys.  As for Syria, Iran, North Korea, and the other
> countries to which export of strong encryption is still illegal, you can
> rest assured that they have all purchased domestic versions in the
> United States and replaced the crippled versions in most installations,
> and the 128-bit crippled versions will still work anyway with the
> crippled keys.
I am pleased to know all those activists out there whose lives may rely on
strong crypto have easy access to a "strong" version of windows instead of an
export-quality version their government would very much rather they had...
0
Dave
11/22/2005 1:34:41 AM
Salaam!

Dave Howe wrote:

 > hajj abujamal wrote:
 >> Windows 98SE deployed 128-bit encryption, the first export versions
 >> had crippled keys.  As for Syria, Iran, North Korea, and the other
 >> countries to which export of strong encryption is still illegal,
 >> you can rest assured that they have all purchased domestic versions
 >> in the United States and replaced the crippled versions in most
 >> installations, and the 128-bit crippled versions will still work
 >> anyway with the crippled keys.

 > I am pleased to know all those activists out there whose lives may
 > rely on strong crypto have easy access to a "strong" version of
 > windows instead of an export-quality version their government would
 > very much rather they had ...

    No one whose life may depend on encryption would ever rely on 
Microsoft to protect their communications.

    But we're way off-topic ~ the question was whether some Windows' 
128-bit encryption APIs (export versions beginning with Win98SE) were 
crippled in a way that would prevent Steve's telephony application 
from using them.  They're not.

    Whether Microsoft can be trusted in this area (and any Microsoft 
cryptologic APIs are reliably secure), is another question entirely, 
and not only because Microsoft products are notoriously insecure.

    I use PGP6.5.8ckt ~ the last open source version of PGP when Phil 
Zimmerman owned it.  I and my correspondents create unique RSA v4 
"channel keys" for use only with one pair of correspondents, exchange 
those public keys only between ourselves, using verified keys and a 
key-exchange protocol to secure that one-time exchange, and those 
unique and exclusive RSAv4 keys then exchange 256-bit symmetric 
session keys whenever we communicate.  Those RSA public keys never see 
a keyserver and move only once, and we just barely trust them.

    Trust Microsoft?  Never in a million years.

was-salaam,
abujamal

0
hajj
11/23/2005 8:35:53 PM
Reply:

Web resources about - Part 1A: Securing an even more secure connection ... - grc.thinktank

Connection - Wikipedia, the free encyclopedia
Text is available under the Creative Commons Attribution-ShareAlike License ;additional terms may apply. By using this site, you agree to the ...

iMedia Connection: Interactive Marketing News, Features, Podcasts and Video - iMediaConnection.com
High-quality data, if not used properly, can still lead marketers to make bad decisions. Consider these common ways that numbers are used to ...

HTTP persistent connection - Wikipedia, the free encyclopedia
... tacked on to an existing protocol. If the browser supports keep-alive, it adds an additional header to the request: Following this, the connection ...

CareerSonar Turns Facebook Friends Into Job Connections
Looking for a job ? Among your Facebook friends lies the potential for employment. CareerSonar , a new service, brings together a person’s connections ...

Ben Garcia gives Penrith Panthers a new French connection
Should he jag a game in the NRL, Ben Garcia will become just the third genuine French import to do so.

Man Charged With Aggravated Arson In Connection To Columbus Warehouse Fire
Police have charged 30-year-old Robin Toms with aggravated arson.

Facebook becomes more adept at dealing with crappy connections
... to get a decent phone signal to allow you to post a photo of your meal. Joking aside, in countries where people are struggling with 2G connections ...

Adam Savage from 'MythBusters' has an incredible connection to the 'Star Wars' franchise
Adam Savage, co-host of the popular " MythBusters " television show, soured on the plot of "Interstellar." But when it comes to the newest films ...

French authorities detain suspects in connection to attacks 10 months apart
CNN French authorities detain suspects in connection to attacks 10 months apart CNN A forensic scientist works near a Paris cafe on Saturday, ...

UK Police Make Arrest in Connection With VTech Hacking
British law enforcement officials arrest a 21-year-old man in connection with attack on toy maker VTech that exposed 6 million parents and children ...

Resources last updated: 12/22/2015 4:08:01 AM