... 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.

-- 
Darren New, San Diego CA, USA (PST)
   "Coding without comments is like
    driving without turn signals."

Post a reply to this message

On 04/05/2011 05:50 PM, 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.

How about mailing it to you every 6 weeks in case you forgot it? (Yes, 
I've seen systems that do this.)

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

On 04/05/2011 17: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.

You know what's worse?

A company that requires you to send files to them electronically using 
SFTP, requires that it uses public key authentication, and emails you 
the private key that you're supposed to use, unencrypted.

People, the entire *point* of public key cryptography is that you should 
never do this! >_<

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> A company that requires you to send files to them electronically using 
> SFTP, requires that it uses public key authentication, and emails you 
> the private key that you're supposed to use, unencrypted.

  I thought the private key can only be used to decrypt, not to encrypt.
(Unless the public key can be created from the private key, which might be
the case.)

-- 
                                                          - Warp

Post a reply to this message

Le 2011/05/05 12:37, Warp a écrit :
> Invisible<voi### [at] devnull>  wrote:
>> A company that requires you to send files to them electronically using
>> SFTP, requires that it uses public key authentication, and emails you
>> the private key that you're supposed to use, unencrypted.
>
>    I thought the private key can only be used to decrypt, not to encrypt.
> (Unless the public key can be created from the private key, which might be
> the case.)
>

Normaly, you should first create your private decryption key.
Then, from that key, you generate the public encryption key. That key 
can be transmited unencrypted.

Post a reply to this message

Alain <aze### [at] qwertyorg> wrote:
> Le 2011/05/05 12:37, Warp a écrit :
> > Invisible<voi### [at] devnull>  wrote:
> >> A company that requires you to send files to them electronically using
> >> SFTP, requires that it uses public key authentication, and emails you
> >> the private key that you're supposed to use, unencrypted.
> >
> >    I thought the private key can only be used to decrypt, not to encrypt.
> > (Unless the public key can be created from the private key, which might be
> > the case.)
> >

> Normaly, you should first create your private decryption key.
> Then, from that key, you generate the public encryption key. That key 
> can be transmited unencrypted.

  That's not what I was asking.

-- 
                                                          - Warp

Post a reply to this message

On 05/05/2011 05:37 PM, Warp wrote:
> Invisible<voi### [at] devnull>  wrote:
>> A company that requires you to send files to them electronically using
>> SFTP, requires that it uses public key authentication, and emails you
>> the private key that you're supposed to use, unencrypted.
>
>    I thought the private key can only be used to decrypt, not to encrypt.

An asymmetric encryption algorithm has an encryption key and a seperate 
(but related) decryption key. Which one is the "public" key depends on 
which one you make public.

If you make the encryption part public, then people can use it to 
encrypt stuff and send it to you securely. If you make the decryption 
part public, you can use it to sign stuff which other people can verify.

[In some algorithms, either key can be used for encryption, obviously 
with the other key becoming the decryption key. For other algorithms, 
the two keys are not equal and only one can be used for encryption or 
decryption. But that doesn't really alter the point above.]

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

On 5/5/2011 9:37, Warp wrote:
> Invisible<voi### [at] devnull>  wrote:
>> A company that requires you to send files to them electronically using
>> SFTP, requires that it uses public key authentication, and emails you
>> the private key that you're supposed to use, unencrypted.
>
>    I thought the private key can only be used to decrypt, not to encrypt.

It depends on the algorithm. RSA can go either way. Otherwise, you wouldn't 
be able to sign and encrypt with the same key.

In either case, sending the "private" key over cleartext and then using it 
for authentication is just as broken as sending your password in cleartext. 
Moreso, because you'd think someone smart enough to use encryption for 
authentication would be smart enough to know that's not how you do it.

-- 
Darren New, San Diego CA, USA (PST)
   "Coding without comments is like
    driving without turn signals."

Post a reply to this message

Le 05/05/2011 20:34, Warp a écrit :
> Alain <aze### [at] qwertyorg> wrote:
>> Le 2011/05/05 12:37, Warp a écrit :
>>> Invisible<voi### [at] devnull>  wrote:
>>>> A company that requires you to send files to them electronically using
>>>> SFTP, requires that it uses public key authentication, and emails you
>>>> the private key that you're supposed to use, unencrypted.
>>>
>>>    I thought the private key can only be used to decrypt, not to encrypt.
>>> (Unless the public key can be created from the private key, which might be
>>> the case.)
>>>
> 
>> Normaly, you should first create your private decryption key.
>> Then, from that key, you generate the public encryption key. That key 
>> can be transmited unencrypted.
> 
>   That's not what I was asking.
> 

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.

Using the public key to encrypt allows to restrict the number of people
able to read the clear: only the private key can decrypt. It's a kind of
"For these people only".

Using the private key to encrypt is stranger, it would be "From this
people only".


Usually, the private key is used to crypt a checksum of the message
(signing), so that the users of the public key can verify that the
holder of the private key did in fact that operation.

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.

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.

Now, there is also weakness in algorithms, and rainbow book for the some
low length of keys.

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).

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)


-- 
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 00:38, Darren New wrote:

> In either case, sending the "private" key over cleartext and then using
> it for authentication is just as broken as sending your password in
> cleartext. Moreso, because you'd think someone smart enough to use
> encryption for authentication would be smart enough to know that's not
> how you do it.

If you're using passwords for authentication, it's almost infeasible to 
not make the system extremely fragile. Public key authentication is a 
sophisticated system which solves almost all of these problems... except 
that these people managed to do it so completely wrong as to trivially 
circumvent any extra security provided.

Actually, the key they sent us was password protected. And they sent us 
the password in a separate email. But really, how long is it going to 
take a password cracker to figure out the 8-digit random alphanumeric 
code they used for a password? That's even assuming the two emails 
didn't trickle across the Internet right next to each other in the first 
place.

Still, it's not a major company or anything. *cough* Pfizer *cough*

Post a reply to this message

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