Re: MD5 collisions found - alternative?
Robert Trebula wrote: Maybe you have already noticed - collisions have been found in MD5 hashing algorithm: http://eprint.iacr.org/2004/199.pdf http://www.freedom-to-tinker.com/archives/000664.html http://www.unixwiz.net/techtips/iguide-crypto-hashes.html My question is: Is there an easy way to make my debian sid installation use something else (better) than md5 for various things? Namely SHA-1 with some longer output in PAM. I think cryptanalysts have 'cracked' pretty much all of them, though with practically prohibitive costs of cracking them (eg, 2^50 for SHA-0). http://www.mail-archive.com/[EMAIL PROTECTED]/msg02554.html http://www.freedom-to-tinker.com/archives/000661.html However, a 2^50 chance, as opposed to the ideal 2^160 still strikes me as pretty good chances. Maybe I'm just not paranoid enough to be a cryptographer ;-). My personal thought is that you could make the hash more secure simply by running md5 and SHA1 (maybe pepper on another one for good luck) across a single stream at the same time, and simply xor the resultant hashes together. You could pretty much add up the cost of the attacks against the keys. An exploration of this approach has just been uploaded to CPAN as Digest::SV1. It's at; http://search.cpan.org/dist/Digest-SV1 Sam. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: MD5 collisions found - alternative?
Bartosz Fenski aka fEnIo wrote: Collisions have been found? Collisions were always. Every hashing algorithm makes collisions... that's just natural. They found way to generate two input values that makes the same hash. That's still long way before they can generate input having hash of another input. That's exactly what they did - found two matching values using substantially less than the square root of the key space of iterations. They reckoned ~~2^50 iterations to find a matching block for a given SHA-0 checksum. With some heavy duty FPGA's you can build circuits to crack that space pretty quickly, today, with enough money. ie, they found an algorithm and beat the birthday paradox by a few orders of magnitude. Sam. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: running services in their own little world
hanasaki wrote: Any package in Debian that will automatically run all /etc/init.d based deamons in jail / chroot? Whilst it is not automatic, you may wish to investigate the Linux vserver project; http://www.linux-vserver.net/ There is a package in Debian for it (util-vserver, and kernel-patch-ctx), but it is perptually out of date, so go to the source. In essence, vserver is something of a souped-up chroot environment - vservers can be built via `debootstrap', or a simple copy from a master image. Most services can then be installed without modification in their own complete, minimalist debian environment, and filesystem unification (implemented via special types of hard links) means that there can be minimal duplication of binaries and libraries between each vserver. Aside from dpkg/apt databases, each vserver can consume as little as 5MB extra disk space. It covers much of the same ground as FreeBSD Jails, but is more complete, designed to provide independent, secure UNIX environments rather than constrain a particular service. Fork bombs, CPU and memory resource attacks are all handled with varying levels of grace. Work on the development branch, for 2.6, is beginning to include integration with the Class-based Kernel Resource Management project (http://ckrm.sourceforge.net/ - an IBM OSS project). This will (hopefully) eventually provide resource management for everything else. One very secure configuration is to configure the vservers on a host on non-routable IP addresses, and use `fwbuilder', in combination with the kernel option CONFIG_IP_NF_NAT_LOCAL to set up appropriate SNAT, DNAT and filtering rules to connect the external IP range of the host to the internal, non-routable vservers. In summary, using vserver + fwbuilder, you can configure multi-tier, firewalled collections of Debian GNU/Linux hosts on a single system. -- Sam Vilain, sam /\T vilain |T net, PGP key ID: 0x05B52F13 (include my PGP key ID in personal replies to avoid spam filtering) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: linux random capabilities ...
Jean-Francois Dive [EMAIL PROTECTED] wrote: i was talking to a friend, and he was describing the inability of PC based security devices to have proper pseudo-random number generation. This sounds to me that i needed some investigation. My general question is: does someone ever heard about any type of cryptographic attack using flaws in the random number generation ? There is no such thing as randomness. Only order of infinite complexity. - _The Holographic Universe_, Michael Talbot Apparently there was an attack on early Netscape browsers that attacked the PRNG; see http://www.counterpane.com/yarrow.html There's a white paper on the topic there too. I think TCP sequence number prediction might be another example - see http://www.engarde.com/software/seqnum.php The linux kernel keeps an `entropy pool', which is stirred every time you press a key, access the disk, move the mouse, and with a patch from Robert Love's site (http://www.tech9.net/rml/linux/), every time the network is used too (very necessary for servers in racks IMHO). You can get random numbers out via /dev/random or /dev/urandom. These are cryptographically strong, though they don't come out at one hell of a rate. Unless, of course, your Intel motherboard has a hardware entropy collector (gets its numbers from ambient heat fluctuations, apparently). And you have turned that option on in the Linux kernel compile. In the userspace side of things, there's the Math::TrulyRandom Perl module, which uses fluctuations in the system timer to get some of that much-loved entropy. This takes some time but also produces pretty good random numbers. -- Sam Vilain, [EMAIL PROTECTED] WWW: http://sam.vilain.net/ 7D74 2A09 B2D3 C30F F78E GPG: http://sam.vilain.net/sam.asc 278A A425 30A9 05B5 2F13 The end move in politics is always to pick up a gun. BUCKMINSTER FULLER
Re: utilisateur backup
Boris Daix [EMAIL PROTECTED] wrote:
- Can I safely give an SSH key to my backup user without any
passphrase so that it could be automated via cron ?
You can use `ssh-keygen -f single_action_key' to create a key for remote
execution of scripts.
On the remote end, add this key to the `.ssh/authorized_keys' file. You should
add a forced command so that only one command may be executed with that key.
For rsync(1), you need to capture the exact switches of the rsync server
command. To do this, you can use this script on the destination server:
#!/usr/bin/perl
open CAPTURE, $ENV{HOME}/capture.log;
print CAPTURE @ARGV\n;
close CAPTURE;
Then add --rsync-path=/path/to/script to your rsync command line. This
will leave something similar to the following in the destination
~/capture.log:
--server -vlgtpr --partial . yourhost
So, you would use an authorized_keys entry like this (all one line):
command=rsync --server -vlogDtpr --partial .
yourhost,no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty,1024
35 23...2334 Server backup key
For more complete security, you could add a `chroot' jail to the above
command.
- Is amanda appropriate for this task and would it be more secure
to use it instead ?
- If it is unsecure, how would I do such backups without having to
enter passpgrase/passwd ?
System backups are always an easy entry point, very often they contain
things like secret keys to encryption, etc that will allow a malicious
user to pretend to be the machine that they have access to the backups of.
Protect your backups carefully!
--
Sam Vilain, [EMAIL PROTECTED] WWW: http://sam.vilain.net/
7D74 2A09 B2D3 C30F F78E GPG: http://sam.vilain.net/sam.asc
278A A425 30A9 05B5 2F13
Real Programmers don't write in Fortran. Fortran is for wimp
engineers who wear white socks. They get excited over finite state
analysis and nuclear reactor simulation.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: More SSH Fun (X11 forwarding)
Yes, I found that. ssh is setting DISPLAY to localhost:X, but only adding an xauth entry for `uname -n`/unix:X hofmann:~$ ssh compileit compileit:~$ xauth list compileit/unix:11 MIT-MAGIC-COOKIE-1 e212a6688726a059503e0c9535289c17 compileit:~$ echo $DISPLAY localhost:11.0 compileit:~$ xload X11 connection rejected because of wrong authentication. X connection to localhost:11.0 broken (explicit kill or server shutdown). compileit:~$ xauth add localhost/unix:11 MIT-MAGIC-COOKIE-1 \ e212a6688726a059503e0c9535289c17 compileit:~$ xload X11 connection rejected because of wrong authentication. X connection to localhost:11.0 broken (explicit kill or server shutdown). compileit:~$ xauth add localhost:11 MIT-MAGIC-COOKIE-1 \ e212a6688726a059503e0c9535289c17 compileit:~$ xload compileit:~$ I thought it was just because the system has a non-standard localhost config where gethostbyname(localhost) == gethostbyname(`uname -n`) != 127.0.0.1. Anyway, this isn't the correct forum for this discussion - I've logged a bug in the BTS - number 152250. Cheers, Sam. On Mon, 1 Jul 2002 13:24:34 -0700 Anne Carasik [EMAIL PROTECTED] wrote: Hi all, I'm having really weird problem with X11 forwarding and two Debian boxes. I can login with OpenSSH and scp and everything else no problem. However, when I try to launch an xterm, I get either: can't open DISPLAY Or the display is set to server:10.0. I don't have this problem SSH'ing into any RH boxes. The version I'm running on both the client and server is: OpenSSH_3.4p1 Debian 1:3.4p1-2, SSH protocols 1.5/2.0, OpenSSL 0x0090604f Let me know if you have any ideas. Running the client and server in both verbose and debugging modes provides me with nothing useful :( -Anne -- .-.__.``. Anne Carasik, System Administrator .-.--. _...' (/) (/) ``' gator at cacr dot caltech dot edu (O/ O) \-' ` -==.', Center for Advanced Computing Research ~`~~ -- Sam Vilain, [EMAIL PROTECTED] Easyspace: an accredited ICANN GPG: http://sam.vilain.net/sam.ascregistrar web hosting company 7D74 2A09 B2D3 C30F F78E Have your domain run by techies 278A A425 30A9 05B5 2F13 with a clue. www.easyspace.com Acid is not for every brain - only the healthy, happy, wholesome, handsome, hopeful, humorous, high-velocity should seek these experiences. This elitism is totally self-determined. Unless you are self-confident, self-directed, self-selected, please abstain. - Dr. Timothy Leary, Pd.D. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: CERT Advisory CA-2002-19 Buffer Overflow in Multiple DNS Resolver Libraries
J.H.M. Dassen (Ray) [EMAIL PROTECTED] wrote: Does anyone know if this affects Debian? This has been fixed; see http://bugs.debian.org/151342 for details. Excellent. To summarise that bug report for the benefit of those interested, if you are running any of the following packages: bind9 bind9-host libbind-dev libdns5 libisc4 liblwres1 libisccc0 ibisccfg0 dnsutils lwresd They should be version 9.2.1-3 or higher, which were uploaded to unstable approximately 6 hours ago (Mon, 1 Jul 2002 00:16:31 -0600). bind 8 is also vulnerable (see http://bugs.debian.org/151247) If you are running any of the the following packages: bind bind-dev Then you need version 8.3.3-1 or higher, which were uploaded to unstable approximately 12 hours ago (Sun, 30 Jun 2002 21:48:10 -0600). The fixed packages do not appear to be available yet on security.debian.org Cheers, -- Sam Vilain, [EMAIL PROTECTED] WWW: http://sam.vilain.net/ 7D74 2A09 B2D3 C30F F78E GPG: http://sam.vilain.net/sam.asc 278A A425 30A9 05B5 2F13 I regret to say that we of the FBI are powerless to act in cases of oral-genital intimacy, unless it has in some way obstructed interstate commerce. J EDGAR HOOVER -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
CERT Advisory CA-2002-19 Buffer Overflow in Multiple DNS Resolver Libraries
call the CERT hotline for more information. Getting security information CERT publications and other security information are available from our web site http://www.cert.org/ To subscribe to the CERT mailing list for advisories and bulletins, send email to [EMAIL PROTECTED] Please include in the body of your message subscribe cert-advisory * CERT and CERT Coordination Center are registered in the U.S. Patent and Trademark Office. __ NO WARRANTY Any material furnished by Carnegie Mellon University and the Software Engineering Institute is furnished on an as is basis. Carnegie Mellon University makes no warranties of any kind, either expressed or implied as to any matter including, but not limited to, warranty of fitness for a particular purpose or merchantability, exclusivity or results obtained from use of the material. Carnegie Mellon University does not make any warranty of any kind with respect to freedom from patent, trademark, or copyright infringement. _ Conditions for use, disclaimers, and sponsorship information Copyright 2002 Carnegie Mellon University. Revision History June 28, 2002: Initial release -BEGIN PGP SIGNATURE- Version: PGP 6.5.8 iQCVAwUBPRzRIKCVPMXQI2HJAQFUUAP+JrIx1x3vF0BL7zFcURQSOOIsmEoGzqAP B+xs5kf4Oy5uYRRLASvYFh/XjnyGXIA5v8ECWx00B52PBKi7aPQS5o4Kiz1rxkFf +c5oziLDXNwy4Vj2ArUjdzM47Ghrq8QXHBOoHaK5OWAF6tywbOklHt50T61OWzGu 5WGow8NNw9I= =PbO6 -END PGP SIGNATURE- -- Sam Vilain, [EMAIL PROTECTED] WWW: http://sam.vilain.net/ 7D74 2A09 B2D3 C30F F78E GPG: http://sam.vilain.net/sam.asc 278A A425 30A9 05B5 2F13 In every country and every age, the priest has been hostile to Liberty. - Thomas Jefferson - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
