 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 06/05/2011 08:38, Le_Forgeron wrote:
> Private key and public key are the mirror of each other.
> If you crypt with the public key, only the private key can get it back
> in clear.
> If you crypt with the private key, only the public key ... and so on.
This is true of algorithms like RSA. However, there are algorithms where
the encryption and decryption keys are actually in different formats,
and it is only possible to encrypt with the designated encryption key.
> The RWTF is that the private key should not be generated by the company
> but by the identified people (you). And they should get your public key,
> verify your identity-matching-that-key using a separate *secure*
> channel, and then sign your public key with a trust level and their own
> dedicated key-pair for that purpose.
In this instance, we're only trying to establish a secure channel. If
they got an imposter's key, we won't be able to log in, and the problem
will quickly be rectified. (And the area the attacker temporarily gets
access to is empty until we put data into it, so there's no disclosure
to worry about.)
> The usual private-public key's algorithms allow only to compute the
> public key from the private key, at best.
> If the private key was computable from the public key alone, it wouldn't
> be private any more.
You understand that in principle, it is *always* possible to compute the
private key from the public one, right? It is impossible to prevent
this. All you can do is make it ludicrously expensive to do it.
> For instance DES is weak enough, yet 3DES in some modes (such as Crypt
> with key 1, uncrypt with key 2, crypt again with key 3) is assumed
> strong enough as long as key2 is not key1 or key3 (moreover, DES use an
> internal vector, and some mode propagate/share that vector with the 3
> stages, whereas other modes have their own vector for each stage).
AES exists for a reason. Triple DES is subject to meet-in-the-middle
attacks, and its keyspace is only 168 bits anyway. The keyspace of AES
is potentially much bigger, and in general it is considered far more
secure than any modification of DES.
> And last but not least, usually the asymetric keys (public-private) are
> only used to crypt a "random" symetric key (like XOR) generated for the
> session (or less), because asymetric cyphering is expensive in CPU
> whereas symetric is usually far less.
> Which also means that if part of the data exchange can be guessed (such
> as a standardised header), the eaves-dropper could try to find the
> symetric key in use by comparing the crypted data with the clear one.
> (hence the random appeareance of "no-data" packets in the ssh streams:
> just to make their lifes more difficult)
Any symmetric block cipher worth toffee *must* be able to resist an
attacker with access to both the plaintext and the matching ciphertext
being able to deduce the key, or anything about the key. This is a very
basic property of symmetric block ciphers. Any cipher lacking this
property is trivially insecure. This has nothing to do with public key
cryptography.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 06/05/2011 10:12, Invisible a écrit :
> On 06/05/2011 08:38, Le_Forgeron wrote:
>
>> Private key and public key are the mirror of each other.
>> If you crypt with the public key, only the private key can get it back
>> in clear.
>> If you crypt with the private key, only the public key ... and so on.
>
> This is true of algorithms like RSA. However, there are algorithms where
> the encryption and decryption keys are actually in different formats,
> and it is only possible to encrypt with the designated encryption key.
>
Agreed. Notice the "if" at the start of the lines, please.
>> The usual private-public key's algorithms allow only to compute the
>> public key from the private key, at best.
>> If the private key was computable from the public key alone, it wouldn't
>> be private any more.
>
> You understand that in principle, it is *always* possible to compute the
> private key from the public one, right? It is impossible to prevent
> this. All you can do is make it ludicrously expensive to do it.
It is always possible to *find by exhaustive exploration* of the key
space a private key that would match a public key. But that is not
computation.
Computation implies a better algorithm than "try key, generate next key,
repeat".
>
>> For instance DES is weak enough, yet 3DES in some modes (such as Crypt
>> with key 1, uncrypt with key 2, crypt again with key 3) is assumed
>> strong enough as long as key2 is not key1 or key3 (moreover, DES use an
>> internal vector, and some mode propagate/share that vector with the 3
>> stages, whereas other modes have their own vector for each stage).
>
> AES exists for a reason. Triple DES is subject to meet-in-the-middle
> attacks, and its keyspace is only 168 bits anyway. The keyspace of AES
> is potentially much bigger, and in general it is considered far more
> secure than any modification of DES.
DES was used as an illustration. Moreover, the 3*56 bits of 3DES have a
lower entropy (so, 3*56 bits is *not* 168, at least in cryptography) due
to issue in the model.
I agree that there is better than 3DES, but it is one of the few
algorithms required (and then accepted) everywhere which also can have
dedicated hardware.
--
Software is like dirt - it costs time and money to change it and move it
around.
Just because you can't see it, it doesn't weigh anything,
and you can't drill a hole in it and stick a rivet into it doesn't mean
it's free.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> You understand that in principle, it is *always* possible to compute the
>> private key from the public one, right? It is impossible to prevent
>> this. All you can do is make it ludicrously expensive to do it.
>
> It is always possible to *find by exhaustive exploration* of the key
> space a private key that would match a public key. But that is not
> computation.
No, that's computation. Given an input, it produces a correct output by
a deterministic procedure. That's more or less the definition of a
computable function.
For most algorithms, you can do something faster than that. For example,
for RSA, you just need to factorise a very large composite number. There
are algorithms for doing this much faster than an exhaustive search of
all possible bit patterns. (Although still in the same complexity class.)
It is always /possible/, and often it's less expensive than it
theoretically could be. The important point is for it to be too
expensive to be practical.
(The definition of "practical" varies depending on how valuable whatever
the key protects actually is, of course...)
> DES was used as an illustration. Moreover, the 3*56 bits of 3DES have a
> lower entropy (so, 3*56 bits is *not* 168, at least in cryptography) due
> to issue in the model.
How do you work that one out?
> I agree that there is better than 3DES, but it is one of the few
> algorithms required (and then accepted) everywhere which also can have
> dedicated hardware.
AES is widely supported (though perhaps not quite as widely as DES), and
I'm sure there are plenty of hardware implementations.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 06/05/2011 15:16, Invisible a écrit :
>> DES was used as an illustration. Moreover, the 3*56 bits of 3DES have a
>> lower entropy (so, 3*56 bits is *not* 168, at least in cryptography) due
>> to issue in the model.
>
> How do you work that one out?
IIRC, it's part of the discussion in the SSH RFCs about the number of
secure bits.
Or it was in a SSH book. 3DES should actually be considered insecure, if
it was not for the administrations of USA to have it deployed a lot.
The wiki about 3DES in french states that 3*56 is 112 due to m-i-t-m
attack. The english version states the same, with added comment about
NIST reducing the actual value to something around 80.
--
Software is like dirt - it costs time and money to change it and move it
around.
Just because you can't see it, it doesn't weigh anything,
and you can't drill a hole in it and stick a rivet into it doesn't mean
it's free.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 06/05/2011 15:52, Le_Forgeron wrote:
> Le 06/05/2011 15:16, Invisible a écrit :
>>> DES was used as an illustration. Moreover, the 3*56 bits of 3DES have a
>>> lower entropy (so, 3*56 bits is *not* 168, at least in cryptography) due
>>> to issue in the model.
>>
>> How do you work that one out?
>
> IIRC, it's part of the discussion in the SSH RFCs about the number of
> secure bits.
> Or it was in a SSH book. 3DES should actually be considered insecure, if
> it was not for the administrations of USA to have it deployed a lot.
>
> The wiki about 3DES in french states that 3*56 is 112 due to m-i-t-m
> attack. The english version states the same, with added comment about
> NIST reducing the actual value to something around 80.
Right. So what you're saying is that due to the possibility of a meet in
the middle attack, 3DES is less secure than a well-designed 168-bit
block cipher.
This is different from saying "a 3DES key has less than 168 bits of
entropy". Entropy is a specific property of a piece of data, and a
properly chosen 3DES key would indeed have 168 bits of entropy. What
you're saying is that not all of that entropy actually counts towards
the difficulty of breaking the cipher, which is a different thing.
Also: Yes, DES is obsolete, and even 3DES shouldn't really be used any more.
Three guesses which cipher our VPN tunnel uses...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 5/6/2011 1:12, Invisible wrote:
> This is true of algorithms like RSA. However, there are algorithms where the
> encryption and decryption keys are actually in different formats, and it is
> only possible to encrypt with the designated encryption key.
There are also algorithms where any of many signatures can be generated (not
under control of the person doing the signing), and they can be checked.
This lets you build a signature algorithm that can't be used for encryption.
> In this instance, we're only trying to establish a secure channel.
Then you don't need a certificate at all, so there's no need for both sides
to have a private key.
> You understand that in principle, it is *always* possible to compute the
> private key from the public one, right?
No. It may be possible to describe how to perform that calculation, but it's
trivial to make the possibility of stumbling across the right private key
arbitrarily small.
> AES exists for a reason. Triple DES is subject to meet-in-the-middle
Triple-DES is useful only to those who have DES hardware ubiquitous in their
infrastructure.
--
Darren New, San Diego CA, USA (PST)
"Coding without comments is like
driving without turn signals."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 5/4/2011 9:50, Darren New wrote:
> ... a company that requires you to twice enter a password with upper case,
> lower case, digits, *and* punctuation, and then mails it to you as a
> confirmation in the clear. Sheesh.
The funny thing was, this was a password used to protect my submission of my
resume to a company. So, they wanted this sophisticated and hard-to-crack
password protecting something I *want* people reading anyway. There are
entire websites devoted to distributing your resume as far and wide as possible.
--
Darren New, San Diego CA, USA (PST)
"Coding without comments is like
driving without turn signals."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> In this instance, we're only trying to establish a secure channel.
>
> Then you don't need a certificate at all, so there's no need for both
> sides to have a private key.
Oh, quite.
What's all the more baffling is that last time we set this up, they did
it the correct way. Why this time around they're doing it backwards, I
have no idea.
>> AES exists for a reason. Triple DES is subject to meet-in-the-middle
>
> Triple-DES is useful only to those who have DES hardware ubiquitous in
> their infrastructure.
...or when your provider wants to charge you extra for the tiny piece of
software required to enable AES. ;-)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 06/05/2011 18:11, Darren New wrote:
> The funny thing was, this was a password used to protect my submission
> of my resume to a company. So, they wanted this sophisticated and
> hard-to-crack password protecting something I *want* people reading
> anyway. There are entire websites devoted to distributing your resume as
> far and wide as possible.
The fail.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 4-5-2011 18:50, Darren New wrote:
> ... a company that requires you to twice enter a password with upper
> case, lower case, digits, *and* punctuation, and then mails it to you as
> a confirmation in the clear. Sheesh.
I have seen that a few times. I also complained and they said it was an
automatic feature of the system they use that they can not turn off.
I said that in that case they should warn in a big fluorescent font that
they are going to do that. So I can use a random password and change it
to a level 3 password later.
--
Apparently you can afford your own dictator for less than 10 cents per
citizen per day.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
