Is openssl actually safe now? (was: debian infrastructure ssh key logins disabled, passwords reset)

[BALLABIO GERARDO]

Peter Palfrader wrote:
> Due to the weakness in our openssl's random number generator (see the
> Debian Security Advisory #1571 from a few minutes ago[1]) that affects
> among other things ssh keys we have disabled public key auth on all
> project systems until further notice.

Hi all,
if I understand correctly, the problem was that openssl used some
segment of uninitialized memory as a source of entropy, and the
offending patch cleared it. Reverting the patch obviously restored the
pristine behavior.

However I wonder, is the pristine behavior correct? As far as I know, it
is NOT justified at all to rely on the assumption that uninitialized
memory contains random data. I read that many architectures reset it to
some magic number, e.g., 0xdeadbeef. Is that correct?

If so, and if that was the ONLY entropy source used in generating keys,
then upstream openssl is (and has always been) just as broken as the
patched Debian package. While if it was only used in addition to other
sources, all this is probably a non-issue.

Someone more competent than me please investigate.

Gerardo


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Is openssl actually safe now? (was: debian infrastructure ssh key logins disabled, passwords reset)

[Richard Kettlewell]

BALLABIO GERARDO <[EMAIL PROTECTED]> writes:
> if I understand correctly, the problem was that openssl used some
> segment of uninitialized memory as a source of entropy, and the
> offending patch cleared it.

This is not correct.  Clearing tmpbuf before reading /dev/urandom is
harmless.  The broken change can be found at these URLs:

http://svn.debian.org/viewsvn/pkg-openssl?rev=141&view=rev
http://svn.debian.org/viewsvn/pkg-openssl/openssl/trunk/rand/md_rand.c?rev=141&r1=140&r2=141

> Reverting the patch obviously restored the pristine behavior.
>
> However I wonder, is the pristine behavior correct? As far as I know, it
> is NOT justified at all to rely on the assumption that uninitialized
> memory contains random data. I read that many architectures reset it to
> some magic number, e.g., 0xdeadbeef. Is that correct?

It's harmless (it doesn't make the RNG any worse) but also pointless
(the uninitialized part of the input buffer may well be predictable).

> If so, and if that was the ONLY entropy source used in generating keys,
> then upstream openssl is (and has always been) just as broken as the
> patched Debian package. While if it was only used in addition to other
> sources, all this is probably a non-issue.

The uninitialized data is not the only source of entropy.

ttfn/rjk


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Is openssl actually safe now? (was: debian infrastructure ssh key logins disabled, passwords reset)

[Steve Kemp]

On Wed May 14, 2008 at 10:21:18 +0200, BALLABIO GERARDO wrote:

> If so, and if that was the ONLY entropy source used in generating keys,
> then upstream openssl is (and has always been) just as broken as the
> patched Debian package. 

  It wasn't.

Steve
-- 
Debian GNU/Linux System Administration
http://www.debian-administration.org/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: analyzing popcon data for bogus recommends

[Enrico Zini]

On Tue, May 13, 2008 at 10:51:37PM -0400, Joey Hess wrote:

> It would be nice to have a list which Recommends are ignored/overridden
> the most when installing packages, to identify Recommends that need to be
> downgraded to Suggests. Could we derive such a list from popcon data? I
> think it would need to be done by analyzing each individual popcon data
> submission, so I can't do it as that data is not published.

Yes you can.  Also, there's a xapian database in my home directory
(~enrico/anapop/something IIRC) on people.debian.org that is built with
the popcon data, and you can query that database to quickly get a count
of "submissions having package X AND NOT package Y" and "package X AND
package Y".

That Xapian index indexes popcon submissions as if they were
"documents", and installed packages as if they were "terms".

The database is updated using a weekly cronjob that rescans the whole
popcon database.  I've quickly tried in the past[1] to come out with
ways to hook the indexing process into popcon so that I could do
realitime indexing of the data (it gives an up to date index and doesn't
suck 100% cpu on gluck once a week), but I got the impression that it
required having more discussion than I was motivated to have at the
time.  If more people are interested in using that xapian index, it can
make sense to rehash this.


Ciao,

Enrico

[1] 
http://lists.alioth.debian.org/pipermail/popcon-developers/2007-June/001374.html
-- 
GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini <[EMAIL PROTECTED]>


signature.asc
Description: Digital signature

Re: Is openssl actually safe now? (was: debian infrastructure ssh key logins disabled, passwords reset)

[Miriam Ruiz]

2008/5/14 BALLABIO GERARDO <[EMAIL PROTECTED]>:

>  However I wonder, is the pristine behavior correct? As far as I know, it
>  is NOT justified at all to rely on the assumption that uninitialized
>  memory contains random data. I read that many architectures reset it to
>  some magic number, e.g., 0xdeadbeef. Is that correct?
>
>  If so, and if that was the ONLY entropy source used in generating keys,
>  then upstream openssl is (and has always been) just as broken as the
>  patched Debian package. While if it was only used in addition to other
>  sources, all this is probably a non-issue.

I wonder if there could be some tool that created a big amount of
random keys and statistically check that the system was working
propely. Any chance of a tool like that can exist?

Miry


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Is openssl actually safe now? (was: debian infrastructure ssh key logins disabled, passwords reset)

[David Härdeman]

On Wed, May 14, 2008 10:21, BALLABIO GERARDO wrote:
> Peter Palfrader wrote:
>> Due to the weakness in our openssl's random number generator (see the
>> Debian Security Advisory #1571 from a few minutes ago[1]) that affects
>> among other things ssh keys we have disabled public key auth on all
>> project systems until further notice.
>
> Hi all,
> if I understand correctly, the problem was that openssl used some
> segment of uninitialized memory as a source of entropy, and the
> offending patch cleared it. Reverting the patch obviously restored the
> pristine behavior.
>
> However I wonder, is the pristine behavior correct? As far as I know, it
> is NOT justified at all to rely on the assumption that uninitialized
> memory contains random data. I read that many architectures reset it to
> some magic number, e.g., 0xdeadbeef. Is that correct?
>
> If so, and if that was the ONLY entropy source used in generating keys,
> then upstream openssl is (and has always been) just as broken as the
> patched Debian package. While if it was only used in addition to other
> sources, all this is probably a non-issue.

No no...in essence upstream OpenSSL did the following (after a quick
comparison of the Debian and upstream versions, please excuse any
oversimplifications):

a) allocate a buffer
b) add contents of unitialized buffer to entropy pool
c) get random data into buffer
d) add contents of initialized buffer to entropy pool

If the entropy pool is properly coded, there is no negative effect of
adding data which may or may not be truly random to the pool (i.e. you
cannot degrade the quality of the pool no matter what you add). Therefore
step b) might add some entropy or it might do nothing at all, depending on
how truly random the uninitialized data is, but it won't hurt.

The goal of the patch that was used in Debian's OpenSSL was to placate
valgrind by removing step b) as valgrind complained about the use of
uninitialized memory (here it was one of the few cases where it might be
legit to do so).

Unfortunately, step d) was *also* removed by that patch. And therein lies
the bug.

-- 
David Härdeman


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: conglomeration packages (Re: Will nvidia-graphics-drivers ever transition to testing?)

[Lennart Sorensen]

On Tue, May 13, 2008 at 10:32:07PM -0400, Filipus Klutiero wrote:
> I don't follow you. iceweasel, for example, is not independent from, say, 
> libnspr.

If they come from one source package, then they all build together.  If
they do not, then it's a dynamicly linked library and each can be built
and updated independantly.  kernel modules have to be rebuilt if the
sources change (just like any application of course) but also if the
kernel is changed (which an application does not, not even when
libraries change) which is hence a rebuild requirement external to the
package itself.  That's what is different.

-- 
Len Sorensen


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

db.debian.org/password.html : Why ~/.ssh/id_dsa.pub to setup OpenSSH for RSA

[Osamu Aoki]

Hi,

Recent openssl issue lead me to http://db.debian.org/password.html and
made me wonder why script example uses DSA key while main text only
talks about RSA key.

| Alternatively, you can do without a password and use PGP to manipulate your
| LDAP information through the mail gateway and use SSH RSA Authentication to
| access the servers. To setup OpenSSH for RSA you need to first generate a
| private RSA key using ssh-keygen and select a good passphrase for it. Then 
send
| the public portion of the key to the LDAP directory:
| 
| gpg --clearsign < ~/.ssh/id_dsa.pub | mail [EMAIL PROTECTED]
| 
| NB: Only version 2 RSA keys are accepted. Version 1 RSA keys (i.e. 
identity.pub
| files) will not work.


If main text is s/RSA/RSA\/DSA/g , I understand script example but ...

Is there any reason to use DSA key insted of RSA key(~/.ssh/id_rsa.pub) ?

Just curious,

Osamu


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: SAGE packages for Debian

[Timothy G Abbott]

Yes, I realize there is not much time left.  I'm also quite busy for the 
next week or two, after which point I should have time to work on this 
again.  The precise release timeline is very helpful.


I won't be able to reasonably maintain this much software in Debian in the 
long term, but I will try to get everything into a release-ready condition 
before the Lenny freeze.


The main task that needs doing is generating patches fixing the various 
(shared) library issues in upstream packages.  Help with this, especially 
during the next couple weeks, could be very high-impact work, since 
ideally we want to give the upstream time to do a release after applying 
the patches we generate to fix their library versioning issues.


Send mail to [EMAIL PROTECTED] to coordinate this, as we've 
done the relevant work for a couple of the packages already.


The other help that this effort needs is people to maintain these packages 
in Debian.  The list of packages needing maintainers is available from 
; looking at the individual package page 
RFP bugs blocking #455292, you can see whether each package is essentially 
ready for upload or require additional work (which I detail in each case).
If you're a Debian maintainer or developer and want to maintain any of 
these packages, feel free to take the packages, set yourself as 
maintainer, and upload them.


-Tim Abbott

On Sun, 11 May 2008, Holger Levsen wrote:


Hi,

wow, great! You're aware that you need to be done in just a bit more than six
weeks to achieve your goal of being part of lenny?
http://release.debian.org/emails/release-update-200801


regards,
Holger




--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: db.debian.org/password.html : Why ~/.ssh/id_dsa.pub to setup OpenSSH for RSA

[Luk Claes]

Osamu Aoki wrote:
> Hi,
> 
> Recent openssl issue lead me to http://db.debian.org/password.html and
> made me wonder why script example uses DSA key while main text only
> talks about RSA key.

The text talks about RSA keys as they are preferred over DSA keys.

> | Alternatively, you can do without a password and use PGP to manipulate your
> | LDAP information through the mail gateway and use SSH RSA Authentication to
> | access the servers. To setup OpenSSH for RSA you need to first generate a
> | private RSA key using ssh-keygen and select a good passphrase for it. Then 
> send
> | the public portion of the key to the LDAP directory:
> | 
> | gpg --clearsign < ~/.ssh/id_dsa.pub | mail [EMAIL PROTECTED]
> | 
> | NB: Only version 2 RSA keys are accepted. Version 1 RSA keys (i.e. 
> identity.pub
> | files) will not work.
> 
> 
> If main text is s/RSA/RSA\/DSA/g , I understand script example but ...
> 
> Is there any reason to use DSA key insted of RSA key(~/.ssh/id_rsa.pub) ?

On the contrary, it's better to use RSA keys as they can be bigger and
are faster.

Cheers

Luk


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: db.debian.org/password.html : Why ~/.ssh/id_dsa.pub to setup OpenSSH for RSA

[Adam D. Barratt]

On Wed, 2008-05-14 at 19:50 +0200, Luk Claes wrote:
> Osamu Aoki wrote:
> > Hi,
> > 
> > Recent openssl issue lead me to http://db.debian.org/password.html and
> > made me wonder why script example uses DSA key while main text only
> > talks about RSA key.
> 
> The text talks about RSA keys as they are preferred over DSA keys.

I assume Osamu was confused by the fact that this paragraph mentions RSA
consistently:

> > |   use SSH RSA Authentication 
> > to
> > | access the servers. To setup OpenSSH for RSA you need to first generate a
> > | private RSA key using ssh-keygen and select a good passphrase for it. 
> > Then send
> > | the public portion of the key to the LDAP directory:

and then suggests using the following:

> > | gpg --clearsign < ~/.ssh/id_dsa.pub | mail [EMAIL PROTECTED]
  ^^^

in order to send your /RSA/ key :) (I'd guess the preceding text
mentioned DSA at one point).

Adam


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Is openssl actually safe now? (was: debian infrastructure ssh key logins disabled, passwords reset)

[Ivan Jager]

On Wed, 14 May 2008, David Härdeman wrote:

If the entropy pool is properly coded, there is no negative effect of
adding data which may or may not be truly random to the pool (i.e. you
cannot degrade the quality of the pool no matter what you add). Therefore
step b) might add some entropy or it might do nothing at all, depending on
how truly random the uninitialized data is, but it won't hurt.


I think that might depend on how not truly random the data is. For 
example, suppose the pool is coded to simply xor the new entropy with the 
pool. This works great when the entropy is distributed evenly through all 
the bits. If you treat it as a black box, it may seem that no matter what 
entropy you add, you can't make the pool any worse. However, if the 
entropy you add happens to be a copy of the pool...


Anyways, that doesn't really apply, since it isn't adding unitialized 
memory to the pool, it's simply using it as the initial value for the 
pool. I guess it's possible the uninitialized values just happen to cancel 
out the entropy that would later be added to the pool, but that seems 
extremely unlikely. In general, I think it would increase the entropy a 
little.


I'm pretty sure openssl uses something better than xor, but I don't see 
how you could code a pool so it wouldn't be possible to degrade the 
quality by adding the right fake entropy.



The goal of the patch that was used in Debian's OpenSSL was to placate
valgrind by removing step b) as valgrind complained about the use of
uninitialized memory (here it was one of the few cases where it might be
legit to do so).

Unfortunately, step d) was *also* removed by that patch. And therein lies
the bug.


What made me really sad, was that b) already had an #ifndef PURIFY around 
it. The ./Configure script already had an option that would do the right 
thing. If you simply google for purify, you would quickly find out it is a 
proprietary valgrind equivalent.


Did the person who came up with the patch not wonder why there was an 
#ifndef around the thing he was commenting out? It seems really silly to 
leave an #ifndef around a comment, without bothering to check what it was 
supposed to change.


Anyways, Debian is still my favorite distro, even though it's becoming a 
bit too nebie oriented for my liking. (This seems to be a common trend.)


Not a DD,
Ivan

Re: Is openssl actually safe now? (was: debian infrastructure ssh key logins disabled, passwords reset)

[Steinar H. Gunderson]

On Wed, May 14, 2008 at 03:33:52PM -0400, Ivan Jager wrote:
> I think that might depend on how not truly random the data is. For  
> example, suppose the pool is coded to simply xor the new entropy with the 
> pool.

It's not -- it's hashed in using a cryptographic hash function.

/* Steinar */
-- 
Homepage: http://www.sesse.net/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

SSH keys: DSA vs RSA (was: Alioth and SSH: restored)

[Ben Finney]

Roland Mas <[EMAIL PROTECTED]> writes:

> - Keys submitted through the web interface are now filtered, and only
>   RSA keys end up in your authorized_keys file.  Don't even try
>   putting DSA keys in your authorized_keys2 file, the use of that file
>   has been disabled (and it'll be deleted anyway).

Could you explain the rationale for this? My impression was that DSA
was recommended over RSA.

-- 
 \ "My house is on the median strip of a highway. You don't really |
  `\notice, except I have to leave the driveway doing 60 MPH."  -- |
_o__)Steven Wright |
Ben Finney


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: package for configuration - Some suggestions

[Timothy G Abbott]

You can make packages to do configuration, but there are tricky issues 
involved in making sure that the right thing happens when the packages 
you're configuring are upgraded.


At MIT, we wrote a system of CDBS modules that automates a lot of the work 
involved in making configuration packages.  You can read about (and 
download) it from .


We use this system to configure hundreds of machines administered by 
different people running any Debian or Ubuntu release dating from sarge to 
the present to use various MIT services.



By the way, sarge security support ended a couple of months ago, so I'm 
not sure continuing to run sarge is a good idea.


-Tim Abbott

On Tue, 13 May 2008, Anthony wrote:


Hello

I would like just to have some suggestions...

I have to change the authentification configuration of debian computers 
(lot of computers) at work...! In SARGE


the users will be authenticated on ldap so i need install some package : 
libpam-ldap, libnss-ldap, ldap-utils, nss-updatedb, libnss-db, libpam-ccreds.
Il need change configuration : /etc/nsswitch.conf, /etc/ldap.conf, 
/etc/libnss-ldap.conf and pam-ldap.conf , pam.d/common*

Create a cron task : "nss-updatedb ldap"
Add some options in resolv.conf

I have thought about create a package with dependencies and postinstall 
script to change configuration!!!

I can't create configuration file and add them in the package, can I?

Is it a good think? Have you any suggestion?

Thank you


Anthony


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]





--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: SSH keys: DSA vs RSA (was: Alioth and SSH: restored)

[The Fungi]

On Thu, May 15, 2008 at 08:09:12AM +1000, Ben Finney wrote:
> Could you explain the rationale for this? My impression was that DSA
> was recommended over RSA.

DSA was recommended over RSA in years gone by for reasons of
freedom, until late 2000 when MIT's 17-year US patent (4405829)
expired on the c=(m^e)%n function and it was subsequently released
into the public domain (though they actually released it into the PD
two weeks ahead of the patent expiration, IIRC).
-- 
{ IRL(Jeremy_Stanley); PGP(9E8DFF2E4F5995F8FEADDC5829ABF7441FB84657);
SMTP([EMAIL PROTECTED]); IRC([EMAIL PROTECTED]); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER([EMAIL PROTECTED]);
MUD([EMAIL PROTECTED]:6669); WWW(http://fungi.yuggoth.org/); }


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: SSH keys: DSA vs RSA (was: Alioth and SSH: restored)

[brian m. carlson]

On Thu, May 15, 2008 at 08:09:12AM +1000, Ben Finney wrote:

Roland Mas <[EMAIL PROTECTED]> writes:


- Keys submitted through the web interface are now filtered, and only
  RSA keys end up in your authorized_keys file.  Don't even try
  putting DSA keys in your authorized_keys2 file, the use of that file
  has been disabled (and it'll be deleted anyway).


Could you explain the rationale for this? My impression was that DSA
was recommended over RSA.


It used to be that RSA was patented in the United States, and so only
DSA, DH, or ElGamal algorithms were appropriate for use in main.

Another reason DSA may be preferred is that it produces smaller
signatures than RSA.  The reason DSA is preferred over RSA for GnuPG
keys is because (AIUI) the keyring maintainers no longer accept v3 keys,
but only v4, which for a while meant that DSA was the only option.
(GnuPG now generates v4 RSA keys as well.)

Still another reason DSA may be preferred over RSA is that it is
conjectured that solving the hard problem underlying DSA (the
Diffie-Hellman Problem) is as difficult as computing discrete logarithms
(the Discrete Logarithm Problem), while the underlying hard problem for
RSA (the RSA Problem) is conjectured to be as difficult as the Factoring
Problem.  If one can solve the Discrete Logarithm Problem, then one can
factor, but the reverse is not true.  Thus, it is conjectured that DSA
is based on a harder problem than RSA.

There are reasons not to prefer DSA.  It has a short key size, usually
limited to 1024 bits, which is not enough for continued security.
Because all signatures are made in the field of q, a 160-bit prime, thus
making them no longer than 160 bits, brute-forcing the algorithm is
easier than with RSA.  Also, DSA absolutely requires a good random
number generator for every signature.  If the nonce is not chosen
randomly, it will leak bits of the key.  This is true for all discrete
logarithm algorithms.  Therefore, anyone who had a DSA key has had it
compromised, and RSA is just as good a choice for a new key.

--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only
troff on top of XML: http://crustytoothpaste.ath.cx/~bmc/code/thwack
OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: SAGE packages for Debian

[Ondrej Certik]

On Wed, May 7, 2008 at 10:16 PM, Timothy G Abbott <[EMAIL PROTECTED]> wrote:
> That's probably a good plan, especially since the sandbox is apparently
> going to be eliminated eventually (and it sounds like arpack and delaunay
> are on the list of things likely to be merged into mainline scipy)
>
> 
>
> I'll send the python-scipy maintainers a note and see what they think.

Is Sage really depending on the sandbox? I think it's not a good idea
to depend on something that is just a sandbox. :)

Anyway, as the comaintainer of python-scipy, I think there is no
problem creating couple more packages for this in DPMT and removing
them when python-scipy has this functionality.

Ondrej


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: SSH keys: DSA vs RSA (was: Alioth and SSH: restored)

[brian m. carlson]

On Wed, May 14, 2008 at 11:12:26PM +, brian m. carlson wrote:

Also, DSA absolutely requires a good random
number generator for every signature.  If the nonce is not chosen
randomly, it will leak bits of the key.  This is true for all discrete
logarithm algorithms.  Therefore, anyone who had a DSA key has had it
compromised, and RSA is just as good a choice for a new key.


I apologize.  Using the same nonce more than once or revealing the nonce
does not leak bits of the key; it immediately and trivially reveals the
private key.  See Applied Cryptography, page 492.

--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only
troff on top of XML: http://crustytoothpaste.ath.cx/~bmc/code/thwack
OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: SSH keys: DSA vs RSA (was: Alioth and SSH: restored)

[Steve Greenland]

On 14-May-08, 18:12 (CDT), "brian m. carlson" <[EMAIL PROTECTED]> wrote: 
> Therefore, anyone who had a DSA key has had it compromised...

Shouldn't that be "anyone who had a DSA key *created by the flawed
version of openssl* has had it compromised..."? Or are you asserting
something stronger?

Steve

-- 
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world.   -- seen on the net


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: SSH keys: DSA vs RSA (was: Alioth and SSH: restored)

[Steinar H. Gunderson]

On Wed, May 14, 2008 at 06:22:37PM -0500, Steve Greenland wrote:
>> Therefore, anyone who had a DSA key has had it compromised...
> Shouldn't that be "anyone who had a DSA key *created by the flawed
> version of openssl* has had it compromised..."? Or are you asserting
> something stronger?

No. Any key who had a single DSA signature created by the flawed version of
OpenSSL should be considered compromised. DSA requires a secret, random
number as part of the signature process; if someone figures it out, or you
use the same number twice, the entire secret key falls.

/* Steinar */
-- 
Homepage: http://www.sesse.net/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: SSH keys: DSA vs RSA (was: Alioth and SSH: restored)

[Steinar H. Gunderson]

On Wed, May 14, 2008 at 11:12:26PM +, brian m. carlson wrote:
> If one can solve the Discrete Logarithm Problem, then one can
> factor, but the reverse is not true.

This is the first time I've ever heard anyone claim this; I've seen people
and textbooks claim they're roughly equivalent, but not that this is a
one-way street. Do you have any references?

/* Steinar */
-- 
Homepage: http://www.sesse.net/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: SSH keys: DSA vs RSA

[Russ Allbery]

Steve Greenland <[EMAIL PROTECTED]> writes:
> "brian m. carlson" <[EMAIL PROTECTED]> wrote: 

>> Therefore, anyone who had a DSA key has had it compromised...

> Shouldn't that be "anyone who had a DSA key *created by the flawed
> version of openssl* has had it compromised..."? Or are you asserting
> something stronger?

He's asserting something stronger.  As I understand it, if you use a
perfectly valid and strong DSA key with a weak nonce (such as from a
broken random number generator), you just revealed your DSA key to someone
who knows what to look for and can brute-force or otherwise determine the
nonce.

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: conglomeration packages (Re: Will nvidia-graphics-drivers ever transition to testing?)

[Filipus Klutiero]

Le May 14, 2008 09:41:02 am Lennart Sorensen, vous avez écrit :
> On Tue, May 13, 2008 at 10:32:07PM -0400, Filipus Klutiero wrote:
> > I don't follow you. iceweasel, for example, is not independent from, say,
> > libnspr.
>
> If they come from one source package, then they all build together.  If
> they do not, then it's a dynamicly linked library and each can be built
> and updated independantly.  kernel modules have to be rebuilt if the
> sources change (just like any application of course) but also if the
> kernel is changed (which an application does not, not even when
> libraries change) which is hence a rebuild requirement external to the
> package itself.
Your second parenthesis is wrong. Just like LKM-s when the stock kernels' 
ABINAME is bumped, applications need to be rebuilt when the ABI of one of the 
libraries they link to changes in a way which is not backwards-compatible. 
You can check http://wiki.debian.org/OngoingTransitions for examples of 
library transitions.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: SSH keys: DSA vs RSA (was: Alioth and SSH: restored)

[brian m. carlson]

On Thu, May 15, 2008 at 02:00:25AM +0200, Steinar H. Gunderson wrote:

On Wed, May 14, 2008 at 11:12:26PM +, brian m. carlson wrote:

If one can solve the Discrete Logarithm Problem, then one can
factor, but the reverse is not true.


This is the first time I've ever heard anyone claim this; I've seen people
and textbooks claim they're roughly equivalent, but not that this is a
one-way street. Do you have any references?


I read it somewhere, probably on a PGP forum, but apparently that was
incorrect.  According to http://portal.acm.org/citation.cfm?id=894497 :

  To summarize: solving the discrete logarithm problem for a composite
  modulus is exactly as hard as factoring and solving it modulo primes.

I stand corrected.

--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only
troff on top of XML: http://crustytoothpaste.ath.cx/~bmc/code/thwack
OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: Is openssl actually safe now?

[Goswin von Brederlow]

Ivan Jager <[EMAIL PROTECTED]> writes:

> On Wed, 14 May 2008, David Härdeman wrote:
>> If the entropy pool is properly coded, there is no negative effect of
>> adding data which may or may not be truly random to the pool (i.e. you
>> cannot degrade the quality of the pool no matter what you add). Therefore
>> step b) might add some entropy or it might do nothing at all, depending on
>> how truly random the uninitialized data is, but it won't hurt.
>
> I think that might depend on how not truly random the data is. For
> example, suppose the pool is coded to simply xor the new entropy with
> the pool. This works great when the entropy is distributed evenly
> through all the bits. If you treat it as a black box, it may seem that
> no matter what entropy you add, you can't make the pool any
> worse. However, if the entropy you add happens to be a copy of the
> pool...

That would require you to

a) know the contents of the pool
   More entropy gets added later so you have to forsee what will be
   added.

b) be able to influence what is actually added

   The buffer itself isn't actualy added from what I read but
   hashed. So you have to device the buffer in such a way that the
   hashed valued cancel out the pool contents. You have to break the
   hashing function.

> I'm pretty sure openssl uses something better than xor, but I don't
> see how you could code a pool so it wouldn't be possible to degrade
> the quality by adding the right fake entropy.

You use a hash function to make it impossible (actually just verry
hard) to control the pattern actually being added. The hash function
will not destroy entropy (unless it is broken) from the input but
destroys patterns.

>> The goal of the patch that was used in Debian's OpenSSL was to placate
>> valgrind by removing step b) as valgrind complained about the use of
>> uninitialized memory (here it was one of the few cases where it might be
>> legit to do so).

And clearly, since the adding of the memory was the only use of the
memory in that function, the right thing would have been to initialize
the memory or not add it at all. And I mean don't call the function
with an uninitialized buffer in the first palce instead of changing
the function to ignore any buffer given.

Simplified the code comes to this:

void add(char* buf) {
 for(i = 0; i < size; i += 20) {
  add_buf_to_pool(buf, i);
  buf += i;
 }
}

'buf' is only ever used to be added to the pool in the function. There
is no other use of it there.

And the patch commented out the 'add_buf_to_pool' call instead of
looking for where 'add' was called with an uninitialized buffer.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: SSH keys: DSA vs RSA

[Goswin von Brederlow]

Russ Allbery <[EMAIL PROTECTED]> writes:

> Steve Greenland <[EMAIL PROTECTED]> writes:
>> "brian m. carlson" <[EMAIL PROTECTED]> wrote: 
>
>>> Therefore, anyone who had a DSA key has had it compromised...
>
>> Shouldn't that be "anyone who had a DSA key *created by the flawed
>> version of openssl* has had it compromised..."? Or are you asserting
>> something stronger?
>
> He's asserting something stronger.  As I understand it, if you use a
> perfectly valid and strong DSA key with a weak nonce (such as from a
> broken random number generator), you just revealed your DSA key to someone
> who knows what to look for and can brute-force or otherwise determine the
> nonce.

The DSA signing uses (secret key + random) in the signature and that
sum is trivial to compute given the signed message and public key. The
security of DSA relies solely on the fact that random can't be guessed
so you can't compute the secret key from the sum.

With the bug in Debians openssl random is one of 2^15 numbers for a
given cpu and key size. If you don't know the cpu used then multiply
by 2 (32bit or 64bit) and again by 2 (big or little endian).

So all you have to do is to try out 32768 random numbers (or 131072)
and check if that gives you the secret key.

Also if you have 2 messages signed with the same random number you can
compute the secret key. It is more complicated then this but
simplified boils down to is computing k given (k + r) * Message1 ==
Signature1 and (k + r) * Message2 == Signature2.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

openssh-blacklist for !Debian

[Martin Langhoff]

Hi Kees, Jamie, DDs,

I am looking at hosts that are runing other linuxen that may have weak
keys now, or see those weak keys uploaded inadvertently in the future.

Is there a straightforward way to get hosts that are !(Debian|Ubuntu)
to use that blacklist? PermitBlacklistedKeys support in openssh-server
seems to be a Debian/Ubuntu patch (and can't even find a mention of it
in the changelog).

cheers,



m
--


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

[DSA 1571-1] Heimdal

[Brian May]

Apparently, Heimdal in Debian also is affected. I am not aware of any 
solution other then to manually regenerate all keys.


Brian May
--- Begin Message ---

I strongly advise all readers of this list that use Debian or might have
users in your realm (or any realms for which cross-realm key exchange as
been performed) to read:

http://lists.debian.org/debian-security-announce/2008/msg00152.html

This vulnerability will effect any Heimdal distribution built using any
Debian package of OpenSSL version 0.9.8c-1 or higher.

All long term keys that were generated with this version of OpenSSL
and are not derived from a password MUST be changed.

Any short term keys that are generated from a vulnerable KDC should be
considered suspect.

Jeffrey Altman



smime.p7s
Description: S/MIME Cryptographic Signature
--- End Message ---

ssl problems: gpg affected?

[Norbert Preining]

On Do, 15 Mai 2008, Steinar H. Gunderson wrote:
> No. Any key who had a single DSA signature created by the flawed version of
> OpenSSL should be considered compromised. DSA requires a secret, random

Does this extend to gpg keys and its signatures? That would make quite
an impact.

Best wishes

Norbert

---
Dr. Norbert Preining <[EMAIL PROTECTED]>Vienna University of Technology
Debian Developer <[EMAIL PROTECTED]> Debian TeX Group
gpg DSA: 0x09C5B094  fp: 14DF 2E6C 0307 BE6D AD76  A9C0 D2BF 4AA3 09C5 B094
---
You step in the stream,
But the water has moved on.
This page is not here.
   --- Windows Error Haiku


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: ssl problems: gpg affected?

[Karl Goetz]

On Thu, 2008-05-15 at 08:09 +0200, Norbert Preining wrote:
> On Do, 15 Mai 2008, Steinar H. Gunderson wrote:
> > No. Any key who had a single DSA signature created by the flawed version of
> > OpenSSL should be considered compromised. DSA requires a secret, random
> 
> Does this extend to gpg keys and its signatures? That would make quite
> an impact.

The DSA said no.
kk

> 
> Best wishes
> 

> 
-- 
Karl Goetz <[EMAIL PROTECTED]>


signature.asc
Description: This is a digitally signed message part