[jitsi-dev] OTR key generation concern


#1

Sorry, I wasn't on the list but saw this message and had to reply so
here it is inline and my response just after.

···

----
Sent by: Ralf Skyper Kaiser skyper at thc.org
Thu Nov 21 14:22:30 CET 2013

using /dev/urandom is the correct way (not /dev/random). /dev/urandom
uses a hash function to generate an endless stream of random numbers.

For the sake of crypto arguement /dev/urandom is 'as strong as
/dev/random' unless the underlying hash function has a serious weakness.

regards,

ralf
----

So, this is true as long as the entropy pool of the kernel is not
reaching 0 estimate values of "true randomness".

Once this happens, /dev/random blocks until it goes up to a certain
value where urandom does not. At that point, you simply *can't* consider
the values to be cryptographically strong. The SHA hash is used to avoid
to expose the state of the entropy pool.

Citing the kernel documentation:

--
The two other interfaces are two character devices /dev/random and
/dev/urandom. /dev/random is suitable for use when very high quality
randomness is desired (for example, for key generation or one-time
pads), as it will only return a maximum of the number of bits of
randomness (as estimated by the random number generator) contained in
the entropy pool.

The /dev/urandom device does not have this limit, and will return as
many bytes as are requested. As more and more random bytes are
requested without giving time for the entropy pool to recharge, this
will result in random numbers that are merely cryptographically strong.
For many applications, however, this is acceptable.
--

Now, we can argue that it is very difficult for an attacker to know the
state of the entropy pool at the exact time you generate your key and
use that as some pratical attack. It is very unlikely but still that
does not mean you shouldn't use the best strongest random values
available for long term keys especially when it generated once.

Cheers!
David


#2

Sorry, I wasn't on the list but saw this message and had to reply so
here it is inline and my response just after.

[...]

The /dev/urandom device does not have this limit, and will return as
many bytes as are requested. As more and more random bytes are
requested without giving time for the entropy pool to recharge, this
will result in random numbers that are merely cryptographically strong.
For many applications, however, this is acceptable.
--

Now, we can argue that it is very difficult for an attacker to know the
state of the entropy pool at the exact time you generate your key and
use that as some pratical attack. It is very unlikely but still that
does not mean you shouldn't use the best strongest random values
available for long term keys especially when it generated once.

yes, that's exactly what it means ("for many [crypto] application, however,
this [urandom] is acceptable"). Jitsi falls right into that statement.

Assuming bug-free /dev/urandom (and /dev/random):
The attack that would break urandom would mean an attack on the hashing
algorithm. If this happens then you have bigger worries than your OTR keys
(for example you would have to redevelop some other parts of the security
protocol as this would no longer be secure as well).

Jitsi shall use urandom as described in the kernel docs.

Cheers!

···

On Thu, Nov 21, 2013 at 3:41 PM, David Goulet <dgoulet@ev0ke.net> wrote:

David

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#3

> Sorry, I wasn't on the list but saw this message and had to reply so
> here it is inline and my response just after.
>
> [...]

> The /dev/urandom device does not have this limit, and will return as
> many bytes as are requested. As more and more random bytes are
> requested without giving time for the entropy pool to recharge, this
> will result in random numbers that are merely cryptographically strong.
> For many applications, however, this is acceptable.
> --
>
> Now, we can argue that it is very difficult for an attacker to know the
> state of the entropy pool at the exact time you generate your key and
> use that as some pratical attack. It is very unlikely but still that
> does not mean you shouldn't use the best strongest random values
> available for long term keys especially when it generated once.
>

yes, that's exactly what it means ("for many [crypto] application, however,
this [urandom] is acceptable"). Jitsi falls right into that statement.

I'll have to strongly disagree with you here. For long term OTR key
generation, this is plain wrong. OTR uses Diffie-Hellman which
*absolutely* needs the strongest random generator available meaning
strong cryptographic values. Its security is based on that premise.

There is *no* reason to compromise with urandom since you are not sure
that you'll get that guarantee of strong random values.

I just think that when you can get the best random values for a use case
like OTR keys, it should be done since it is available.

Assuming bug-free /dev/urandom (and /dev/random):
The attack that would break urandom would mean an attack on the hashing
algorithm. If this happens then you have bigger worries than your OTR keys
(for example you would have to redevelop some other parts of the security
protocol as this would no longer be secure as well).

Agreed, if SHA1 breaks, there is bigger problem :).

David

···

On 21 Nov (15:53:38), Ralf Skyper Kaiser wrote:

On Thu, Nov 21, 2013 at 3:41 PM, David Goulet <dgoulet@ev0ke.net> wrote:

Jitsi shall use urandom as described in the kernel docs.

Cheers!
> David
>
> _______________________________________________
> dev mailing list
> dev@jitsi.org
> Unsubscribe instructions and other list options:
> http://lists.jitsi.org/mailman/listinfo/dev
>

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#4

Hi,

/dev/urandom is suitable and strong enough for DH keys (and long term DH
keys).

ps that's also what openssl uses by default and that's what most of the
internet runs on (with DH keys generated from /dev/urandom...)...

regards,

ralf

···

On Thu, Nov 21, 2013 at 4:13 PM, David Goulet <dgoulet@ev0ke.net> wrote:

On 21 Nov (15:53:38), Ralf Skyper Kaiser wrote:
> On Thu, Nov 21, 2013 at 3:41 PM, David Goulet <dgoulet@ev0ke.net> wrote:
>
> > Sorry, I wasn't on the list but saw this message and had to reply so
> > here it is inline and my response just after.
> >
> > [...]
>
>
> > The /dev/urandom device does not have this limit, and will return as
> > many bytes as are requested. As more and more random bytes are
> > requested without giving time for the entropy pool to recharge, this
> > will result in random numbers that are merely cryptographically strong.
> > For many applications, however, this is acceptable.
> > --
> >
> > Now, we can argue that it is very difficult for an attacker to know the
> > state of the entropy pool at the exact time you generate your key and
> > use that as some pratical attack. It is very unlikely but still that
> > does not mean you shouldn't use the best strongest random values
> > available for long term keys especially when it generated once.
> >
>
> yes, that's exactly what it means ("for many [crypto] application,
however,
> this [urandom] is acceptable"). Jitsi falls right into that statement.

I'll have to strongly disagree with you here. For long term OTR key
generation, this is plain wrong. OTR uses Diffie-Hellman which
*absolutely* needs the strongest random generator available meaning
strong cryptographic values. Its security is based on that premise.

There is *no* reason to compromise with urandom since you are not sure
that you'll get that guarantee of strong random values.

I just think that when you can get the best random values for a use case
like OTR keys, it should be done since it is available.

>
> Assuming bug-free /dev/urandom (and /dev/random):
> The attack that would break urandom would mean an attack on the hashing
> algorithm. If this happens then you have bigger worries than your OTR
keys
> (for example you would have to redevelop some other parts of the security
> protocol as this would no longer be secure as well).

Agreed, if SHA1 breaks, there is bigger problem :).

David

>
> Jitsi shall use urandom as described in the kernel docs.

>
>
> Cheers!
> > David
> >
> > _______________________________________________
> > dev mailing list
> > dev@jitsi.org
> > Unsubscribe instructions and other list options:
> > http://lists.jitsi.org/mailman/listinfo/dev
> >

> _______________________________________________
> dev mailing list
> dev@jitsi.org
> Unsubscribe instructions and other list options:
> http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#5

Hi,

/dev/urandom is suitable and strong enough for DH keys (and long term DH
keys).

Disagree. LibOTR uses explicitely GCRY_STRONG_RANDOM that feeds on
/dev/random. Libgcrypt also explicitely mention that for long term keys
you need strong crypo. values that are not guaranteed by urandom.

ps that's also what openssl uses by default and that's what most of the
internet runs on (with DH keys generated from /dev/urandom...)...

Openssl does that indeed from their command line tool but the API can
let you seed back the pool with /dev/random. I wouldn't cite the
Internet security state as a good example to be honest, it's quite
horrible all around the place.

I can't find any details on why they switched to urandom other then this
commit message back in 2001 (and to be honest this leaves me a bit in a
"wtf state"):

https://git.openssl.org/gitweb/?p=openssl.git;a=commit;h=e02cc10ea4fa7ded67203bfa89628d8fc49c8fab

My guess is that speed is more important for them considering that the
"usual workload" is session key. Probably don't want to block https
request for 2 minutes while gathering entropy :).

The kernel documentation states clearly that long term keys should use
true randomness (guaranteed with /dev/random), libgcrypt also mention
that, and every other documentation. I can't think of a cryptographer
that will compromise for "not really sure strong values" ...

I feel like we are going to disagree for a while here so I guess the
Jitsi/otr4j folks can decide here what to do considering the amount of
information they have on the subject.

Cheers!
David

···

On 21 Nov (18:10:45), Ralf Skyper Kaiser wrote:

regards,

ralf

On Thu, Nov 21, 2013 at 4:13 PM, David Goulet <dgoulet@ev0ke.net> wrote:

> On 21 Nov (15:53:38), Ralf Skyper Kaiser wrote:
> > On Thu, Nov 21, 2013 at 3:41 PM, David Goulet <dgoulet@ev0ke.net> wrote:
> >
> > > Sorry, I wasn't on the list but saw this message and had to reply so
> > > here it is inline and my response just after.
> > >
> > > [...]
> >
> >
> > > The /dev/urandom device does not have this limit, and will return as
> > > many bytes as are requested. As more and more random bytes are
> > > requested without giving time for the entropy pool to recharge, this
> > > will result in random numbers that are merely cryptographically strong.
> > > For many applications, however, this is acceptable.
> > > --
> > >
> > > Now, we can argue that it is very difficult for an attacker to know the
> > > state of the entropy pool at the exact time you generate your key and
> > > use that as some pratical attack. It is very unlikely but still that
> > > does not mean you shouldn't use the best strongest random values
> > > available for long term keys especially when it generated once.
> > >
> >
> > yes, that's exactly what it means ("for many [crypto] application,
> however,
> > this [urandom] is acceptable"). Jitsi falls right into that statement.
>
> I'll have to strongly disagree with you here. For long term OTR key
> generation, this is plain wrong. OTR uses Diffie-Hellman which
> *absolutely* needs the strongest random generator available meaning
> strong cryptographic values. Its security is based on that premise.
>
> There is *no* reason to compromise with urandom since you are not sure
> that you'll get that guarantee of strong random values.
>
> I just think that when you can get the best random values for a use case
> like OTR keys, it should be done since it is available.
>
> >
> > Assuming bug-free /dev/urandom (and /dev/random):
> > The attack that would break urandom would mean an attack on the hashing
> > algorithm. If this happens then you have bigger worries than your OTR
> keys
> > (for example you would have to redevelop some other parts of the security
> > protocol as this would no longer be secure as well).
>
> Agreed, if SHA1 breaks, there is bigger problem :).
>
> David
>
> >
> > Jitsi shall use urandom as described in the kernel docs.
>
> >
> >
> > Cheers!
> > > David
> > >
> > > _______________________________________________
> > > dev mailing list
> > > dev@jitsi.org
> > > Unsubscribe instructions and other list options:
> > > http://lists.jitsi.org/mailman/listinfo/dev
> > >
>
> > _______________________________________________
> > dev mailing list
> > dev@jitsi.org
> > Unsubscribe instructions and other list options:
> > http://lists.jitsi.org/mailman/listinfo/dev
>
>
> _______________________________________________
> dev mailing list
> dev@jitsi.org
> Unsubscribe instructions and other list options:
> http://lists.jitsi.org/mailman/listinfo/dev
>

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#6

/dev/urandom is suitable and strong enough for DH keys (and long term DH
keys).

Disagree. LibOTR uses explicitely GCRY_STRONG_RANDOM that feeds on
/dev/random. Libgcrypt also explicitely mention that for long term keys
you need strong crypo. values that are not guaranteed by urandom.

Just for reference: the DH-keys are session keys. The ones you care about
are the public/private DSA key pair.

Ingo


#7

>> /dev/urandom is suitable and strong enough for DH keys (and long term DH
>> keys).
>
> Disagree. LibOTR uses explicitely GCRY_STRONG_RANDOM that feeds on
> /dev/random. Libgcrypt also explicitely mention that for long term keys
> you need strong crypo. values that are not guaranteed by urandom.

Just for reference: the DH-keys are session keys. The ones you care about
are the public/private DSA key pair.

I stand corrected sorry. Thanks! :slight_smile:

David

···

On 21 Nov (20:35:39), Ingo Bauersachs wrote:

Ingo

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#8

From a theoretical point of view, David is right : high-entropy

randomness is required (/dev/random). Practically though, cryptographic
randomness (/dev/urandom) should be good enough for most intents and
purposes. That said, we don't have to argue about which one to use : we
can give the user the option to choose between a "very secure generator"
and a "secure generator".

···

On 11/21/2013 08:43 PM, David Goulet wrote:

On 21 Nov (20:35:39), Ingo Bauersachs wrote:

/dev/urandom is suitable and strong enough for DH keys (and long term DH
keys).

Disagree. LibOTR uses explicitely GCRY_STRONG_RANDOM that feeds on
/dev/random. Libgcrypt also explicitely mention that for long term keys
you need strong crypo. values that are not guaranteed by urandom.

Just for reference: the DH-keys are session keys. The ones you care about
are the public/private DSA key pair.

I stand corrected sorry. Thanks! :slight_smile:

David

Ingo

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#9

Hi,

David, there is not academic attack or practical attack that even remotely
managed to compromise a DSA or DH key generated from a (bug-free)
/dev/urandom (and it has been tried a lot).

George, I would not give the user the choice. If we cant make up our mind
how should the user be able to? The user will end up in a state of
confusion. That's my personal choice which is not always shared by others.

But hey, details. As long as the choices include only 'secure' sources (not
/dev/zero :>) we have nothing to fear.

regards,

ralf

···

On Thu, Nov 21, 2013 at 9:12 PM, George Politis <666f6f@gmail.com> wrote:

From a theoretical point of view, David is right : high-entropy
randomness is required (/dev/random). Practically though, cryptographic
randomness (/dev/urandom) should be good enough for most intents and
purposes. That said, we don't have to argue about which one to use : we
can give the user the option to choose between a "very secure generator"
and a "secure generator".

On 11/21/2013 08:43 PM, David Goulet wrote:
> On 21 Nov (20:35:39), Ingo Bauersachs wrote:
>>>> /dev/urandom is suitable and strong enough for DH keys (and long term
DH
>>>> keys).
>>>
>>> Disagree. LibOTR uses explicitely GCRY_STRONG_RANDOM that feeds on
>>> /dev/random. Libgcrypt also explicitely mention that for long term keys
>>> you need strong crypo. values that are not guaranteed by urandom.
>>
>> Just for reference: the DH-keys are session keys. The ones you care
about
>> are the public/private DSA key pair.
>
> I stand corrected sorry. Thanks! :slight_smile:
>
> David
>
>>
>> Ingo
>>
>>
>> _______________________________________________
>> dev mailing list
>> dev@jitsi.org
>> Unsubscribe instructions and other list options:
>> http://lists.jitsi.org/mailman/listinfo/dev
>>
>>
>> _______________________________________________
>> dev mailing list
>> dev@jitsi.org
>> Unsubscribe instructions and other list options:
>> http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#10

Indeed we don't. urandom sounds like a reasonable choice (which is all we
are about), so the only thing we need now is someone to submit a patch
(that should also not break the other OSes and, ideally, improve security
there as well )

--sent from my mobile

···

On 21 Nov 2013 22:40, "Ralf Skyper Kaiser" <skyper@thc.org> wrote:

Hi,

David, there is not academic attack or practical attack that even remotely
managed to compromise a DSA or DH key generated from a (bug-free)
/dev/urandom (and it has been tried a lot).

George, I would not give the user the choice. If we cant make up our mind
how should the user be able to? The user will end up in a state of
confusion. That's my personal choice which is not always shared by others.

But hey, details. As long as the choices include only 'secure' sources
(not /dev/zero :>) we have nothing to fear.

regards,

ralf

On Thu, Nov 21, 2013 at 9:12 PM, George Politis <666f6f@gmail.com> wrote:

From a theoretical point of view, David is right : high-entropy
randomness is required (/dev/random). Practically though, cryptographic
randomness (/dev/urandom) should be good enough for most intents and
purposes. That said, we don't have to argue about which one to use : we
can give the user the option to choose between a "very secure generator"
and a "secure generator".

On 11/21/2013 08:43 PM, David Goulet wrote:
> On 21 Nov (20:35:39), Ingo Bauersachs wrote:
>>>> /dev/urandom is suitable and strong enough for DH keys (and long
term DH
>>>> keys).
>>>
>>> Disagree. LibOTR uses explicitely GCRY_STRONG_RANDOM that feeds on
>>> /dev/random. Libgcrypt also explicitely mention that for long term
keys
>>> you need strong crypo. values that are not guaranteed by urandom.
>>
>> Just for reference: the DH-keys are session keys. The ones you care
about
>> are the public/private DSA key pair.
>
> I stand corrected sorry. Thanks! :slight_smile:
>
> David
>
>>
>> Ingo
>>
>>
>> _______________________________________________
>> dev mailing list
>> dev@jitsi.org
>> Unsubscribe instructions and other list options:
>> http://lists.jitsi.org/mailman/listinfo/dev
>>
>>
>> _______________________________________________
>> dev mailing list
>> dev@jitsi.org
>> Unsubscribe instructions and other list options:
>> http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#11

Indeed we don't. urandom sounds like a reasonable choice (which is all we

are

about), so the only thing we need now is someone to submit a patch (that
should also not break the other OSes and, ideally, improve security there

as

well )

OTR already uses /dev/urandom (or /dev/random) through Java's SecureRandom.
What we do need to care about is not seeding Fortuna with zeros. Problem
there is that SecureRandom is too slow in case /dev/random is used, so we
can't just use that as a seed for Fortuna unless we set
-Djava.security.egd=file:/dev/./urandom

Ingo


#12

Why not use /dev/urandom for session stuff and /dev/random for
long-term keys and tell the user why he has to wait a few seconds?
Does that make sense?

Regards,
Philipp

···

On Thu, 21 Nov 2013 23:42:49 +0100 Emil Ivov <emcho@jitsi.org> wrote:

Indeed we don't. urandom sounds like a reasonable choice (which is
all we are about), so the only thing we need now is someone to submit
a patch (that should also not break the other OSes and, ideally,
improve security there as well )


#13

Indeed we don't. urandom sounds like a reasonable choice (which is all we

are

about), so the only thing we need now is someone to submit a patch (that
should also not break the other OSes and, ideally, improve security there

as

well )

OTR already uses /dev/urandom (or /dev/random)

Do you mean libotr or otr4j?

through Java's SecureRandom.

I am confused. Does it currently use urandom or random?

What we do need to care about is not seeding Fortuna with zeros.
Problem there is that SecureRandom is too slow in case /dev/random is
used, so we can't just use that as a seed for Fortuna unless we set
-Djava.security.egd=file:/dev/./urandom

I was thinking more along the lines of a custom SecureRandomSpi
implementation (as you also suggested yourself in your earlier mails)
that uses the one we deem appropriate (regardless of property
settings) and that would also select generators on OS X and Windows.

Emil

···

On Fri, Nov 22, 2013 at 12:04 AM, Ingo Bauersachs <ingo@jitsi.org> wrote:

Ingo

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
Jitsi
emcho@jitsi.org PHONE: +33.1.77.62.43.30
https://jitsi.org FAX: +33.1.77.62.47.31


#14

Hi,

I'm concerned that waiting works for the tech-savy but the inpatient user
just says "takes to long, Let's do it without OTR then". I've seen it. It's
a sad world out there.

That you are totally right. However, I strongly believe that informing
the user of WHY this is taking a long time informs the users for the
future and have a "better" understanding of they are actually doing.
After all, UI usability *is* a security feature.

Why give the user a bad experience if there is no academic or practical
evidence that it increases the security (in fact some academics say that
urandom is
more secure than random - but i do not share that view - and this would be
a discussion out of scope for this ML).

As Jurre said, that does *not* make sense to wait for practical attack
before starting using the strongest possible methods available. Yes it
may take sometimes to create that key but it's should not be often and
is a necessary step to educate users.

Cheers!
David

···

On 22 Nov (12:12:19), Ralf Skyper Kaiser wrote:

regards,

ralf

On Fri, Nov 22, 2013 at 12:05 PM, Philipp Überbacher <murks@tuxfamily.org>wrote:

> On Thu, 21 Nov 2013 23:42:49 +0100 > > Emil Ivov <emcho@jitsi.org> wrote:
>
> > Indeed we don't. urandom sounds like a reasonable choice (which is
> > all we are about), so the only thing we need now is someone to submit
> > a patch (that should also not break the other OSes and, ideally,
> > improve security there as well )
>
> Why not use /dev/urandom for session stuff and /dev/random for
> long-term keys and tell the user why he has to wait a few seconds?
> Does that make sense?
>
> Regards,
> Philipp
>
> _______________________________________________
> dev mailing list
> dev@jitsi.org
> Unsubscribe instructions and other list options:
> http://lists.jitsi.org/mailman/listinfo/dev
>

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#15

Hi,

I'm concerned that waiting works for the tech-savy but the inpatient user
just says "takes to long, Let's do it without OTR then". I've seen it. It's
a sad world out there.

Why give the user a bad experience if there is no academic or practical
evidence that it increases the security (in fact some academics say that
urandom is
more secure than random - but i do not share that view - and this would be
a discussion out of scope for this ML).

regards,

ralf

···

On Fri, Nov 22, 2013 at 12:05 PM, Philipp Überbacher <murks@tuxfamily.org>wrote:

On Thu, 21 Nov 2013 23:42:49 +0100 > Emil Ivov <emcho@jitsi.org> wrote:

> Indeed we don't. urandom sounds like a reasonable choice (which is
> all we are about), so the only thing we need now is someone to submit
> a patch (that should also not break the other OSes and, ideally,
> improve security there as well )

Why not use /dev/urandom for session stuff and /dev/random for
long-term keys and tell the user why he has to wait a few seconds?
Does that make sense?

Regards,
Philipp

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#16

That's a possibility, the user has this choice. The important part is
that the user knows why he has to wait a few seconds. If it's not worth
it for him, then so be it.

After reading the link that Jurre van Bergen posted
(http://rdist.root.org/2010/11/19/dsa-requirements-for-random-k-value/)
I'm concerned that my suggestion doesn't even make sense.
Can anyone more knowledgeable about krypto algortihms comment?

Regards,
Philipp

···

On Fri, 22 Nov 2013 12:12:19 +0000 Ralf Skyper Kaiser <skyper@thc.org> wrote:

Hi,

I'm concerned that waiting works for the tech-savy but the inpatient
user just says "takes to long, Let's do it without OTR then". I've
seen it. It's a sad world out there.

Why give the user a bad experience if there is no academic or
practical evidence that it increases the security (in fact some
academics say that urandom is
more secure than random - but i do not share that view - and this
would be a discussion out of scope for this ML).

regards,

ralf


#17

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

I'm concerned that waiting works for the tech-savy but the inpatient user
just says "takes to long, Let's do it without OTR then". I've seen

it. It's

a sad world out there.

That you are totally right. However, I strongly believe that informing
the user of WHY this is taking a long time informs the users for the
future and have a "better" understanding of they are actually doing.
After all, UI usability *is* a security feature.

Why give the user a bad experience if there is no academic or practical
evidence that it increases the security (in fact some academics say that
urandom is
more secure than random - but i do not share that view - and this

would be

a discussion out of scope for this ML).

As Jurre said, that does *not* make sense to wait for practical attack
before starting using the strongest possible methods available. Yes it
may take sometimes to create that key but it's should not be often and
is a necessary step to educate users.

In fact, isn't there a way to make a pop-up box appear when the key is
generating? While the key is being generated, make sure to not be able
to click on the underneath Jitsi instance to chat in. People probably
don't like it that much, but they are safe! :slight_smile:

Please keep in mind, that the average user only generate this key once
every X years.

Jurre

- --
Developer at https://www.useotrproject.org/

···

On 11/22/2013 04:04 PM, David Goulet wrote:

On 22 Nov (12:12:19), Ralf Skyper Kaiser wrote:


#18

OTR already uses /dev/urandom (or /dev/random)

Do you mean libotr or otr4j?

Otr4j

through Java's SecureRandom.

I am confused. Does it currently use urandom or random?

It depends :slight_smile:
Can't tell you on what though without digging in the source of the JDKs,
they switched between the two.

What we do need to care about is not seeding Fortuna with zeros.
Problem there is that SecureRandom is too slow in case /dev/random is
used, so we can't just use that as a seed for Fortuna unless we set
-Djava.security.egd=file:/dev/./urandom

I was thinking more along the lines of a custom SecureRandomSpi
implementation (as you also suggested yourself in your earlier mails)
that uses the one we deem appropriate (regardless of property
settings) and that would also select generators on OS X and Windows.

Windows' SecureRandom is fine (it uses CryptGenRandom), no need to touch it.
No idea about OSX.

Emil

Ingo