Re: [SLUG] downloading debian
Phill wrote: I am downloading debian for the first time to check it out. Is v3.0 (released dec 03) the latest version? I cant find a later version. Phill yep. Woody is the latest. stable (core) .debian. release. grab the 2nd cd if you dont have fast broadband. IMO, it's great for untouched, unmanaged, bulletproof and stable servers, and machines with 32mb ram, or enough ram to open a frame buffer / X desktop comfortably. but so is NetBSD, and FreeBSD. and OpenBSD. and a handful of floppy-disc-distros and USB keychain distros that fit in 5mb/100mb footprints. The latest debian offshoot would be ubuntu though, followed by knoppix. you should probably grab one of those too. as a side note, they put the LiveCD's on magazines and in newsagents theses days,which has the advantage of being ready to go, so no 198mb downloads of security/kernel patches, etc to get a bootable system, a 1 minute install/evaluation, and the livecd's can be copied straight to a HDD for permanence and speed. fedora core 3 also has some nice features, it is still redhat though, which might effect that decision. that said, ubuntu has nice things, e.g., clean, solid gnome with udev/gdev and 2.6.x prelinking. its wierd to have a linux distro that can auto-mount cdr's without setting up some pseudo daemon and waiting for the kernel to lock up in protest. and theres other intangibles too. That kind of retro new-age hippie communist thinking haunts the debian zealots, so its best to keep that kind of innovative talk to yourself. so,if they find out, just tell them they can do it themselves with about 4 hours of configuration, that should sedate them. Toliman. -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] Re: Preventing attacks
[EMAIL PROTECTED] wrote: On Tue, Nov 09, 2004 at 02:25:22PM +1100, James Gregory wrote: On Tue, Nov 09, 2004 at 03:31:50PM +1100, Toliman wrote: and it is 'relatively' secure, in that it would hopefully take a p4 a few hours to brute force... more likely in minutes. How long is 'a few hours'? I didn't think things were that dire. Are you talking about a straight brute force or some kind of known-plaintext attack or what? Isn't the kerberos ticket only valid for a few minutes anyway? So 1 hour, few hours ... doesn't matter at the moment. Matt Yeah, that's the big thing. you have a limited period of time to use the token before you have to request another, losing any benefit to the original token. but if you look at the tools that are used to break in, it isnt a quick process. it usually involves surveillance and/or subversively tapping into less secure systems/users to gain elevated privileges over time. like WEP and other cracking methods, the strategy is to watch the KBC/network segment for traffic, to identify the traffic for extended periods and cryptanalyse the tokens for common data, like the domains used, hosts, passwords, users, vulnerabilities on the infrastructure, things like that. but it is essentially brute-force. it could take 1 attempt, or 20 million. or more. the central idea is to test the keyspace, the possible combinations of keys to choose from. since DES's key is 56 bits, the space to check is reduced, also using differential cryptananlysis and other methods. the same problem does not exist in 3DES, or AES, the brute force combinations are exponentially more difficult, it would require some very kooky math to weaken AES - reduce the possible combinations for a brute force to reduce the time necessary. hours might be pushing it, sure, and CISC/RISC processors are not that fast at non-specific tasks like DES cracking, so it might be a few hundred hours, split over hundreds of machines. anyway ... as long as the master password isn't cracked, and a few other major passwords/logins used to wrap the databases and traffic to and from the KDC, the system is very much secure. the token expires after a few minutes, and the number of DES combinations to brute-force is still a high number, in the order of ~2^53 combinations for DES. however, since DES was/is used to wrap/secure a lot of the data travelling around the economic sectors, there is a lot of value in (very ruthless and organised cartels, organisations, 'family businesses') spending some serious money on distributed parallel processing to break DES before tokens expire. for reference, the EFF proved how feasible it was in 1998, with a self-built FPGA setup, a deadline of 10 days in which to break the challenge, they developed a system to methodically crunch through ~92 billion combinations/day on a limited budget. We searched more than 88 billion keys every second, for 56 hours, before we found the right 56-bit key to decrypt the answer to the RSA challenge http://www.eff.org/Privacy/Crypto/Crypto_misc/DESCracker/HTML/19980716_eff_descracker_pressrel.html there's always the human factor too. http://en.wikipedia.org/wiki/Rubber-hose_cryptanalysis Toliman. -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] Re: Preventing attacks
Ken Foskey wrote: On Mon, 2004-11-08 at 23:27 +1100, James Gregory wrote: faster (and just as secure) block cipher algorithms like DES or Blowfish Foes anyone know the ciphers that kerberos uses? I was going to ask the person that did cryptography in Uni recently :-) i suppose its a good engough reason to break out the Applied Cryptography Book i havent even loked at in oh, 3 years. i had a look for the protocol data, the RFC is woeful but extreme, and complete ... http://www.faqs.org/rfcs/rfc1510.html http://www.cmf.nrl.navy.mil/CCS/people/kenh/kerberos-faq.html http://www.nata2.info/misc/Wireless/A_Real-World_Analysis_of_Kerberos_Password_Security-MIRROR.html Kerberos uses DES, but the encryption method can be negotiated in versions v4. DES is still used in a lot of operational cryptographic applications,and it is 'relatively' secure, in that it would hopefully take a p4 a few hours to brute force... more likely in minutes. Which is why DES has been phased out for at least 5 years, replaced by AES in secure applications. The major thing is, in Krb v5, you can specify the salt, the algorithm and a few other variables to make the TGS/KDC give out more secure keys if you have a need for it. it depends on your KDC, the machine you get your ticket from, so its not something easily modified unless you can replace a working Kerberos system. Suffice to say, Krb is relatively secure for a large scale network. more secure methods are available now, but they all have their inconvenient security-based provisions and features that will make client adoption difficult. there's always the addition of biometric data and variable challenge authentication methods, etc. but its still relying on making the process visibly painful as a reminder of the need for security, etc. Toliman -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] Re: Digital TV card
Ben Buxton wrote: James Gregory [EMAIL PROTECTED] uttered the following thing: Hey all, I just purchased a FusionHDTV card, which I'll be installing this evening. I envisage three use cases for it: 1. Watching TV where I'm sitting in front of the computer. 2. Recording streams off the thing to watch when I have time. 3. Streaming data across the network so I can watch it on (say) my laptop. Is anyone doing any of this stuff, and if so what software are you using to do it? Does it work well? Caveats I bought one of these cards, and am in the process of getting MythTV to work, via Gentoo and the CVS ebuilds. which in hindsight ... it's kind of messy in linux, but from other's reports (mostly anandtech at this stage), DVB software like MythTV is more reliable and less prone to GUI/overlay failures (especially during long recording sessions) which can happen in the Windows FusionHDTV software from DVICO. (the FusionHDTV software now support BDA, so a lot more windows DVR/PVR apps can now be used, including the generally annoying showshifter.) anyway, the quickest way to get this working, download unpack the patched dvb lirc kernel modules from http://www.itee.uq.edu.au/~chrisp/DVICO-Linux/. the modified cx88 tuner modules specific for the DVICO are not yet integrated into linuxtv-dvb or the 2.6.x series kernels, so it's a little messy to install but Chris Pascoe has done a great job of making 4 paragraphs describe the process seamlessly, and it does work well. getting started is relatively quick, you just need to have a /dev/dvb/adapterX/dvrX after the modules are built inserted, and then you need the linuxtv-dvb-apps package to tune channels in, and you can record straight from /dev/dvb. the libdvb packages and linuxtv-dvb-apps you can get from the linuxtv.org website. DVB software packages like freevo, mythtv and kvdr, as well as kaxtv (which uses xine, recommended) or mplayer to actually view and/or test the channels. gmplayer/kaxtv/xine will run dvb://7 Digital, or dvb://ABC HDTV, once the channels are configured. mythtv/freevo needs xmltv (for TV scheduling data), which needs another package called tv_grab_au from http://www.onlinetractorparts.com.au/rohbags/xmltvau/tv_grab_au-0.6.tar.gz , which grabs the tv guides from yahoo.com.au (the XML data comes from d1.com.au). although there are some issues with the d1.com.au feeds (double escaped items, missing ch9 icons, incomplete program listings for hdtv channels, etc. little things), it does work. kindof. i dont know how many other programs apart from kaxtv work seamlessly with DVB, dvbscan (to set the channel) and mplayer (to view/record) are enough to get recording and playback / transcoding to xvid working in a very rough but utilitarian fashion. streaming DVB over a network, you might want to buffer/re-encode via mencode or VLC/VLS, or, use knoppmyth (xebian/gentoox and mythfrontend on an xbox also make a cheap tv frameserver with enough CPU to decode mpeg4 and mpeg2 + ac3 audio), as a frontend to another machine running mythtv as a server. mythweb will allow you to make changes and schedules easily over a local apache/php setup. mythfrontend will also serve this purpose. Toliman. -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] Re: Digital TV card
Ben de Luca wrote: Hi Can this card be used only for HDtv or can I plug my foxtel (after the decoder box) into it and record stuff ? Are there any box'es that can replace the foxtel box ? The card might have Video in plug so u can capture from a set top box box but thats a lot of expense (cheaper capture cards exist). The card supports only SD and HD digital via Terrestrial transmitter. Foxtel digital uses a proprietary encryption method to encode there material and at present known decryption tools, legal or not exist. You have to use a foxtel receiver. Why not mail Chris directly if u have issues with the driver, I am sure he will respond. DVICO FusionHDTV has stereo audio SVHS input. the Lite version does not. it does sync the audio and video fairly well for a $200 non-professional tuner card. there's more than just the encrypted video signal in foxtel digital (DVB-C) vs. Free to Air Digital TV (DVB-T), it's a new class of DVB hardware that is required + a few chips to decode the encrypted bandwidth feeds in hardware. it's easier to just record the Analogue Video from the Foxtel Digital set top box, and record the AC3/mpeg2 audio too. DVICO and Twinhan have mentioned in passing they will support DVB-C for foxtel digital soon -- read that as next century, it's largely dependent on how much cost/computational power/licensing fee is required to decode NDS VideoGuard, the encryption used to lock Foxtel Digital http://www.foxtel.com.au/236_381.htm , and the ability of the hardware to read the Foxtel SIM Card is another problem in itself. on the other side, DVB-C hardware is relatively expensive as well, two PCI devices i have seen are the TerraTec Cinergy 1200 DVB-C, and the Hauppage WinTV DVB-C The tangential problem of having hardware like this is...that it would require a dvb-c internal/external SIM Card reader that would read the contents of the smartcard that contains your personal ID for decoding content. since it's a form of DRM, the likelihood of NDS even considering it would be remote. this would be highly regarded as a bad thingfor NDS, as you could very quietly open the encrypted content of the sim card while it's being operated, a la deCSS, etc. of course, NDS might license the Foxtel Digital hardware from the Set-Top-Box to an OEM manufacturer to play around with, so theres always hope for raw foxtel digital encodes. Toliman -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
