Well, you can slice it in context. In the mid-19th century, the usual age of consent was around 10 to 13.
No, the youngest age of conset was around 10-13, and reading wiki-pedia entries does not constitute research.
Also, when someone married at that age, they were very rarely in their thirties! I'm personally appalled that you can even begin to rationalize this behavior.
Wow, I thought this had to be a troll, but the link looks legit.
The church calls this guy a prophet, just like the ones in biblical times. Maybe I need to use their "Ask a question" link for info on Chesters in the old testament...
15 years old is too young for this guy no matter how you slice it. Sheesh.
Here is the FCC law (which no one cares about, but I brought it up)
1. The limint for directional links is 4W EIRP at 6dBi. That means 1W dBm output (from radio), plus antenna gain. The 6dBi bit is important. The higher gain your antenna, the more you have to reduce output power.
2. For every 3dBi over 6dBi in antenna gain, you need to reduce output power by 1dBm. This means that your effective signal output is higher, while the transmit power from the radio is lower than 1W.
So, here is a handy table of legal radio + antenna pairs starting with the most powerful radio combination first:
1.0 W radio + 6dBi antenna == 4W EIRP 500 mW radio + 9dBi antenna == 4W EIRP 250 mW radio + 12dBi antenna == 4W EIRP 125 mW radio + 15dBi antenna == 4W EIRP
62 mW radio + 18dBi antenna == 4W EIRP
31 mW radio + 21dBi antenna == 4W EIRP
My eventual plan is to set up a site on a mountain with a fairly high gain omnidirectional antenna, and then anyone who wants to connect to the LAN just points at it with a primestar dish.
The problem you are going to run into with more than a few clients associated over a long link like this is contention and timing. You will see network throughput plummet as multiple clients associate and begin talking; leading to massive interference/collision (see timing issues).
Maybe by then someone will have a reversed driver for the atheros / broadcom devices and we can tweak the MAC as needed for this kind of use...
So while it's possible to hack a good range with enough effort, conventional WiFi equipment is still not reliable getting from one side of my house to the other.
I hear this complaint often. The problem is that AP's use weak radio's, especially the cheap ones. Sometimes as low as 30mw.
Client cards use low power, almost always 30mw.
You want good signal? Use two 200mw senao/engenius/teletronics cards (boy, these companies change hands quickly...)
They sell them for $100 at teletronics.com and you can still find the old senao/engenius models on ebay and elsewhere for less.
200mw on both ends of a link lets you cut through the walls in your house, through the neighbors house, and out into the street:-)
Arg, the information link looked like the college site nav bar...
Some observations:
1) It's an illegally amplified system. No one cares about the FCC anyway, but it would be illegal for you to sell or operate this kind of link.
2) The extremely long ping times seems to imply that they were using a regular IBSS connection with the ACK's likely timing out frequently.
The delay's at the IP level are caused by retransmission at layer 2 for links like this, indicating that the link was probably spotty and in need of some timing tweaks.
Did they use the old ad-hoc demo peer to peer mode, which has no ACK's and performs much better over longer links?
Cisco cards are also well known for their quality; perhaps the cisco MAC can adapt to high latency long shots while also working well in infrastructure mode.
Does anyone have more details on exactly how tenuous this link was, and how they pulled it (card settings, cables, antennas?)
As a side note, myself and some others have been wondering how we might go about discerning the exact timing characteristics of different 802.11 MAC implementations using non-exotic hardware (like regular cards in monitor mode).
When you need to measure microseconds (or fractions of them) it gets tricky...
3-DES is not known to be weaker than AES (of any keysize)
I should have clarified keysize and cryptanalytic attacks. In terms of keysize, AES-256 offers a significant advantage over 3-DES, but your other points are well taken.
There are no known weaknesses in either 3-DES (which has had TONS of scrutiny) or AES (which has had less) from a cryptanalytic viewpoint.
Also, some would argue that the infamous NSA involment in the DES S-BOX design is unsettling and another point above for AES. (I'd still like to know the details of the work they did on this...)
Funny you mention that. I'm in the process of building a case mod using an old NeXT station Turbo case for holding two mini-ITX M10000 motherboards.
They fit just perfectly within the case, and there is enough room along the edge where the raised power supply / cooling fins are to place 2 HDD's.
The cooling built into the case also comes in handy for cooling the drives mounted next to it, and the power supply mounted on top.
On a more on-topic note, the NeXT machines were expensive and tied to hardwar: the NeXT Station. A mini-CDR, USB key fob, and java iButton fit in your pocket, and can be used in any system that can boot from CD.
I think this is a crucial difference, but i'm probably wrong (the devil is in the details, and who knows which ones will prove critical and which ones are simply cosmetic).
I've been working on a linux distro for a few months now that is using this combination of technologies. It definitely appears to be a configuration of growing use and interest.
I added the cryptographic iButton to the list as the only piece missing from the live CD / USB fob picture is secure authentication so that when you are accessing your files remotely from any location, you need not fear about Man-in-the-Middle attacks or insecure password / authentication allowing attackers access to your data.
The future trends are moving quickly towards seamless access to data via mobile devices and wireless communications. A trusted operating system on a mini-CDR with a USB key fob storing dynamic data and strong authentication via cryptographic hardware is all you need to access files, music, movies, anything back at home or work with complete security (or, as much security as you can provide given a good OS configuration)
And the best part: it fits in your pocket. You can take it anywhere. You can "phone home" via wireless and reach everything there as if it was local.
With AES encryption of sensitive data on the USB fob you can prevent any kind of unauthorized copying that would reveal private data, and compression added to the mix lets you store a lot more than 256M or so of data as well.
The latest USB devices are capable of throughput in excess of 6 MegaBytes / second, which is more than adequate for most tasks.
Userspace / overlay filesystems with selective encryption, networked access, and secure decentralized distribution are going to make this kind of setup extremely sweet.
Obviously, with a GPS stuck in the phone itself this becomes really trivial, but even with normal phones you can use a variety of techniques, like Time Difference Of Arrival (TDOA) and Angle Of Arrival (AOA) and even Enhanced Observed Time Difference (EOTD) to triangulate the location of a wireless caller.
The carriers are already using this technology across the US, and many phones are now available with GPS integrated.
With 5,200 Watts for Green Destiny, you could use 433 boards these boards for the same power consumption.
The on chip AES is clocked at 12.5Gbps, Entropy at 10Mbps (whitened). Thus you would have
422Ghz of C5 processor power 5.412TB/s of AES (yes, terabytes) 4.22Gbps of true random number generation.
Yeah, these are really rough estimates, but that is a long of bang for your kilowatt buck no matter how you slice it.
With a cutting edge P4 approaching 100W the efficiency of these less powerful but fully capable systems will become increasingly attractive.
I would not be surprised to find bleeding edge processors relegated to gamers and workstations as most computing tasks start migrating towards small, silent, low power systems that simply *work* without eating up desk space, filling a room with fan noise and driving the electricity bill higher with continuous 100's of W draw.
I'd be insulted that you think so little of my intelligence as to ask me questions concerning the minutae of a programming language.
The problem is, this isn't pedantic dick waving over obscure language features. This is C++ 101 - Basic skill level.
Those kinds of mistakes in a code base cause memory problems (incorrect delete), weird behavior artifacts and/or memory leaks (non virtual destructors) etc.
This is the kind of stuff you learn in entry level c++ development, and certainly a fair expectation to have for anyone applying for a c++ development position.
1. How many jobs gained during the "bubble" of the late 90's (that was unsustainable) are factored into that count?
2. How many H1B visas that are unrenewed are part of that count? (Exploitative consulting agencies? They loved to pump up the numbers)
3. How many psuedo-engineers have rightly left the CS/IT job market because they dont have the skills?
I worked with a guy briefly in 2000 that got paid $75/hour, 60 hours a week, for a whole month (before jumping ship to greener pastures in Silicon Valley) to write some horribly broken and incomplete perl CGI code.
Yes, nasty perl CGI that didnt work. It was obvious his skills were at tech college freshman / skilled high schooler level, and yet he was able to pull in an insane wage due to irrational exhuberance.
You hear these stories, and it doesnt really sink in until you see it first hand. Things were severely out of balance.
We are almost out of the hangover. If you are truly skilled, you can find a job with some elbow grease and effort 98% of the time. You may need to relocate, you may need to settle for something less than ideal, but they are out there.
The tech services (specifically programming / engineering) are picking up and we are on course for a return to semi-normality. But against the backdrop of insane compensation and free flowing VC cash, even normalcy appears spartan.
The best thing you can do for a career in IT is to truly love it and find it fascinating. This will keep your skills sharp as you experiment and play with cutting edge technologies on your own, and maybe on your job, and also provide the motivation needed to obtain a deeper understanding of the many details associated with programming, system administration, engineering, etc.
If you are in this field for the money, you wont have the drive to stay afloat.
Pre shared key auth/keying is a bad idea. Public key based authentication with random session keys via integration with RADIUS or Kerberos is much more secure (and should be supported by any WPA capable AP)
This is the way I do it, and although a little clunky, it allows me to keep remote backups of certain directories one three different servers.
First, setup ssh to use pubkey authentication instead of interactive password. You can read the man pages for details but it basically boils down to running keygen on the trusted source:
ssh-keygen -b 2048 -t dsa -f ~/.ssh/identity
Then copy|append the newly created ~/.ssh/identity.pub to the remote hosts into their/home/user/.ssh/authorized_keys file.
Now you can run rsync with ssh as the transport (instead of rsh) by exporting:
export RSYNC_RSH=ssh or also passing --rsh=ssh on the command line.
So to sync directories you could use a find command to update regularly:
while true; do
find . -follow -cnewer.last-sync | grep '.' 1>/dev/null 2>/dev/null
if (( $? == 0 )) ; then
rsync -rz --delete . destination:/some/path/
touch.last-sync
fi
sleep 60 done
Obviously this is pretty hackish and could be improved. But the point is that with ssh and rsync you could do automatic mirroring of specific filesystems or directories to remote locations securely.
This raw output is then fed into a second stage where "statistical whitening" is applied to ensure that the entropy is not just random, but nicely random.
To be fair I should have mentioned the hardware entropy solutions that both Intel (i810, i815, etc) and AMD (76x boards) have available, but they are much smaller offerings in Intel and AMD's product line. Contrast this with VIA which is making the Nehemiah core a centerpiece of existing EPIA boards, like the M10k, and forthcoming boards like the M2.
I read the sample chapter and the table of contents, and this certainly looks like a very useful book for developers.
The random number generation chapter is excellent. Many people overlook this necessity in cryptographic applications unaware that flaws introduced by insecurely random (i.e. predictable) enrtropy sources can render the best PKI, ciphers and authentication mechanisms crippled.
One of the reasons I tend to drool over VIA hardware is that their MiniITX EPIA systems have support for hardware entropy on the CPU via the Nehemiah core, which is also available for a wide variety of OEM/embedded applications.
This means you can use a highly secure entropy source (/dev/hw_random in linux for example) for all of your cryptographic applications, from GPG to ssh to the linux kernel itself (IPSEC). And best of all, you never have to worry about the entropy pool blocking, or reverting to less secure PRNG like/dev/urandom.... I wonder if this book is out on Safari yet.
You have clearly missed my point that placing a file in a public place does not imply distribution (legally tested).
No, as I've stated before, this is not about simply placing a file in a public place. This is about unathorized distribution, aka, "uploading a song" to a RIAA contracted spider / peer.
Quit trying to change the subject.
we are talking about what happened in front of a US Federal Grand Jury.
Like I said previously, this is not about access, this is about actual distribution, i.e. uploading.
Howevevr you miss the point about single vs. multisourvce dosnloading. The process of switching sources is automatic.If you can't show me a session log, I'm sorry, you don't have the remotest bit of proof.
Agreed, which is why they are not using multi-source uploading at all. Not at all. Its all single source uploading from gnutella and kazaa. If they did target a multisource network, they would simply elect to obtain the full content from a single peer at a time.
The multisource upload capability in even peer file sharing implementation (aside from freenet, which is not p2p sharing) is driven by the client. If you have a modified RIAA client explicitly asking for full downloads from a single source, they can get the client to do so.
"Secure MD5 digest" is an oxymoron. Please read the literature.
I'm not going to discuss this further, but while MD5 is questionable as a secure digital signature / encryption challenge mechanism, it is still highly resistant to collision (on the order of 2^64 not considering file length as an identifying factor) which is suitably convincing in a court of law or federal grand jury as you mention, especially when you are dealing with known MD5's for multiple songs, all of which where sucessfully upload from the target peer.
Are you working for one of these companies? Is this why you are so defensive about the techniques?
No, i just find it annoying when serious weaknesses are dismissed out of hand. I have been working on open source peer networking software for many years, and would prefer that legal vulnerabilities are addressed on technical grounds rather than dismissed on legal assumption.
For example, achord and mix networks would provide a very strong layer of anonymity with regards to block sources in a multi-source download as well as caches of encrypted data (i.e. freenet style separation of key and data with onion style routing protection against traffic analysis and achord ensurance against requesting all blocks from a single anonymous source.
Slashdot Mirror
Well, you can slice it in context. In the mid-19th century, the usual age of consent was around 10 to 13.
No, the youngest age of conset was around 10-13, and reading wiki-pedia entries does not constitute research.
Also, when someone married at that age, they were very rarely in their thirties! I'm personally appalled that you can even begin to rationalize this behavior.
Wow, I thought this had to be a troll, but the link looks legit.
The church calls this guy a prophet, just like the ones in biblical times. Maybe I need to use their "Ask a question" link for info on Chesters in the old testament...
15 years old is too young for this guy no matter how you slice it. Sheesh.
I need to quit posting sans-caffeine. The above are for multipoint. For directional the table is as follows:
1.0 W radio + 6dBi antenna == 4W EIRP
500 mW radio + 15dBi antenna == 16W EIRP
250 mW radio + 24dBi antenna == 63W EIRP
Arg, I hate doing the EIRP limit math! *grin*
Here is the FCC law (which no one cares about, but I brought it up)
1. The limint for directional links is 4W EIRP at 6dBi. That means 1W dBm output (from radio), plus antenna gain. The 6dBi bit is important. The higher gain your antenna, the more you have to reduce output power.
2. For every 3dBi over 6dBi in antenna gain, you need to reduce output power by 1dBm. This means that your effective signal output is higher, while the transmit power from the radio is lower than 1W.
So, here is a handy table of legal radio + antenna pairs starting with the most powerful radio combination first:
1.0 W radio + 6dBi antenna == 4W EIRP
500 mW radio + 9dBi antenna == 4W EIRP
250 mW radio + 12dBi antenna == 4W EIRP
125 mW radio + 15dBi antenna == 4W EIRP
62 mW radio + 18dBi antenna == 4W EIRP
31 mW radio + 21dBi antenna == 4W EIRP
My eventual plan is to set up a site on a mountain with a fairly high gain omnidirectional antenna, and then anyone who wants to connect to the LAN just points at it with a primestar dish.
The problem you are going to run into with more than a few clients associated over a long link like this is contention and timing. You will see network throughput plummet as multiple clients associate and begin talking; leading to massive interference/collision (see timing issues).
Maybe by then someone will have a reversed driver for the atheros / broadcom devices and we can tweak the MAC as needed for this kind of use...
So while it's possible to hack a good range with enough effort, conventional WiFi equipment is still not reliable getting from one side of my house to the other.
:-)
I hear this complaint often. The problem is that AP's use weak radio's, especially the cheap ones. Sometimes as low as 30mw.
Client cards use low power, almost always 30mw.
You want good signal? Use two 200mw senao/engenius/teletronics cards (boy, these companies change hands quickly...)
They sell them for $100 at teletronics.com and you can still find the old senao/engenius models on ebay and elsewhere for less.
200mw on both ends of a link lets you cut through the walls in your house, through the neighbors house, and out into the street
Arg, the information link looked like the college site nav bar...
Some observations:
1) It's an illegally amplified system. No one cares about the FCC anyway, but it would be illegal for you to sell or operate this kind of link.
2) The extremely long ping times seems to imply that they were using a regular IBSS connection with the ACK's likely timing out frequently.
The delay's at the IP level are caused by retransmission at layer 2 for links like this, indicating that the link was probably spotty and in need of some timing tweaks.
The 802.11b MAC layer is fairly sensitive to timing latency. (I go into more detail on this article on timing in long 802.11 links)
Did they use the old ad-hoc demo peer to peer mode, which has no ACK's and performs much better over longer links?
Cisco cards are also well known for their quality; perhaps the cisco MAC can adapt to high latency long shots while also working well in infrastructure mode.
Does anyone have more details on exactly how tenuous this link was, and how they pulled it (card settings, cables, antennas?)
As a side note, myself and some others have been wondering how we might go about discerning the exact timing characteristics of different 802.11 MAC implementations using non-exotic hardware (like regular cards in monitor mode).
When you need to measure microseconds (or fractions of them) it gets tricky...
3-DES is not known to be weaker than AES (of any keysize)
I should have clarified keysize and cryptanalytic attacks. In terms of keysize, AES-256 offers a significant advantage over 3-DES, but your other points are well taken.
There are no known weaknesses in either 3-DES (which has had TONS of scrutiny) or AES (which has had less) from a cryptanalytic viewpoint.
Also, some would argue that the infamous NSA involment in the DES S-BOX design is unsettling and another point above for AES. (I'd still like to know the details of the work they did on this...)
Who modded this up? 3-DES is significantly weaker than AES-256 or even 128 (arguably).
3DES is a kludge using the original DES in triplicate because alone it was too easy to brute force the keyspace.
Funny you mention that. I'm in the process of building a case mod using an old NeXT station Turbo case for holding two mini-ITX M10000 motherboards.
They fit just perfectly within the case, and there is enough room along the edge where the raised power supply / cooling fins are to place 2 HDD's.
The cooling built into the case also comes in handy for cooling the drives mounted next to it, and the power supply mounted on top.
On a more on-topic note, the NeXT machines were expensive and tied to hardwar: the NeXT Station. A mini-CDR, USB key fob, and java iButton fit in your pocket, and can be used in any system that can boot from CD.
I think this is a crucial difference, but i'm probably wrong (the devil is in the details, and who knows which ones will prove critical and which ones are simply cosmetic).
I've been working on a linux distro for a few months now that is using this combination of technologies. It definitely appears to be a configuration of growing use and interest.
I added the cryptographic iButton to the list as the only piece missing from the live CD / USB fob picture is secure authentication so that when you are accessing your files remotely from any location, you need not fear about Man-in-the-Middle attacks or insecure password / authentication allowing attackers access to your data.
I talk about some of the features I want in this thread of wanted features / technologies
The future trends are moving quickly towards seamless access to data via mobile devices and wireless communications. A trusted operating system on a mini-CDR with a USB key fob storing dynamic data and strong authentication via cryptographic hardware is all you need to access files, music, movies, anything back at home or work with complete security (or, as much security as you can provide given a good OS configuration)
And the best part: it fits in your pocket. You can take it anywhere. You can "phone home" via wireless and reach everything there as if it was local.
With AES encryption of sensitive data on the USB fob you can prevent any kind of unauthorized copying that would reveal private data, and compression added to the mix lets you store a lot more than 256M or so of data as well.
The latest USB devices are capable of throughput in excess of 6 MegaBytes / second, which is more than adequate for most tasks.
Userspace / overlay filesystems with selective encryption, networked access, and secure decentralized distribution are going to make this kind of setup extremely sweet.
I can't wait for it...
This is all pretty well known to those watching the E911 drama unfold.
The easiest and simplest method for most carriers to comply with E911 is using triangulation. Indeed, bellsouth even posted a nice article about the various ways location can be obtained for cell phone users.
Obviously, with a GPS stuck in the phone itself this becomes really trivial, but even with normal phones you can use a variety of techniques, like Time Difference Of Arrival (TDOA) and Angle Of Arrival (AOA) and even Enhanced Observed Time Difference (EOTD) to triangulate the location of a wireless caller.
The carriers are already using this technology across the US, and many phones are now available with GPS integrated.
Welcome to the future.
Q1 '04
see also the SMP dual C5P mini-itx:
Small is beautiful @ extremetech
with the centaur C5P processor core. Draws about 8W for the chip @ 1Ghz. Lets assume 12W total for network boot.
p g ]
[ see image here: peertech.org/hardware/viarng/image/nano-itx-c5p.j
With 5,200 Watts for Green Destiny, you could use 433 boards these boards for the same power consumption.
The on chip AES is clocked at 12.5Gbps, Entropy at 10Mbps (whitened). Thus you would have
422Ghz of C5 processor power
5.412TB/s of AES (yes, terabytes)
4.22Gbps of true random number generation.
Yeah, these are really rough estimates, but that is a long of bang for your kilowatt buck no matter how you slice it.
With a cutting edge P4 approaching 100W the efficiency of these less powerful but fully capable systems will become increasingly attractive.
I would not be surprised to find bleeding edge processors relegated to gamers and workstations as most computing tasks start migrating towards small, silent, low power systems that simply *work* without eating up desk space, filling a room with fan noise and driving the electricity bill higher with continuous 100's of W draw.
I'd be insulted that you think so little of my intelligence as to ask me questions concerning the minutae of a programming language.
The problem is, this isn't pedantic dick waving over obscure language features. This is C++ 101 - Basic skill level.
Those kinds of mistakes in a code base cause memory problems (incorrect delete), weird behavior artifacts and/or memory leaks (non virtual destructors) etc.
This is the kind of stuff you learn in entry level c++ development, and certainly a fair expectation to have for anyone applying for a c++ development position.
I hope you are kidding, cause this pretty fucking sad otherwise.
On the other hand, I had a developer tell me, straight faced during an interview: "Ask me anything about C++, I will know it. I am an expert".
He struck out 3 for 3.
1. How many jobs gained during the "bubble" of the late 90's (that was unsustainable) are factored into that count?
2. How many H1B visas that are unrenewed are part of that count? (Exploitative consulting agencies? They loved to pump up the numbers)
3. How many psuedo-engineers have rightly left the CS/IT job market because they dont have the skills?
I worked with a guy briefly in 2000 that got paid $75/hour, 60 hours a week, for a whole month (before jumping ship to greener pastures in Silicon Valley) to write some horribly broken and incomplete perl CGI code.
Yes, nasty perl CGI that didnt work. It was obvious his skills were at tech college freshman / skilled high schooler level, and yet he was able to pull in an insane wage due to irrational exhuberance.
You hear these stories, and it doesnt really sink in until you see it first hand. Things were severely out of balance.
We are almost out of the hangover. If you are truly skilled, you can find a job with some elbow grease and effort 98% of the time. You may need to relocate, you may need to settle for something less than ideal, but they are out there.
The tech services (specifically programming / engineering) are picking up and we are on course for a return to semi-normality. But against the backdrop of insane compensation and free flowing VC cash, even normalcy appears spartan.
The best thing you can do for a career in IT is to truly love it and find it fascinating. This will keep your skills sharp as you experiment and play with cutting edge technologies on your own, and maybe on your job, and also provide the motivation needed to obtain a deeper understanding of the many details associated with programming, system administration, engineering, etc.
If you are in this field for the money, you wont have the drive to stay afloat.
Arg, I should proofread. The above will not print leading zeros. Try this instead:
/dev/random
hexdump -e "\"%4.4x%4.4x\n\"" -n 8
hexdump -e "\"%04x%04x\n\"" -n 8 /dev/random
Pre shared key auth/keying is a bad idea. Public key based authentication with random session keys via integration with RADIUS or Kerberos is much more secure (and should be supported by any WPA capable AP)
This is the way I do it, and although a little clunky, it allows me to keep remote backups of certain directories one three different servers.
/home/user/.ssh/authorized_keys file.
.last-sync | grep '.' 1>/dev/null 2>/dev/null .last-sync
First, setup ssh to use pubkey authentication instead of interactive password. You can read the man pages for details but it basically boils down to running keygen on the trusted source:
ssh-keygen -b 2048 -t dsa -f ~/.ssh/identity
Then copy|append the newly created ~/.ssh/identity.pub to the remote hosts into their
Now you can run rsync with ssh as the transport (instead of rsh) by exporting:
export RSYNC_RSH=ssh or also passing --rsh=ssh on the command line.
So to sync directories you could use a find command to update regularly:
while true; do
find . -follow -cnewer
if (( $? == 0 )) ; then
rsync -rz --delete . destination:/some/path/
touch
fi
sleep 60
done
Obviously this is pretty hackish and could be improved. But the point is that with ssh and rsync you could do automatic mirroring of specific filesystems or directories to remote locations securely.
You know that not even noise diodes are secure to attacks?
Yes, as do hardware engineers. If you read the Cryptography Research analysis of the C3 Nehemiah entropy source you can see that it is well designed, using 4 free wheeling oscillators / ring oscillators at different frequencies.
This raw output is then fed into a second stage where "statistical whitening" is applied to ensure that the entropy is not just random, but nicely random.
Its a pretty interesting read: check it out!
Like the Intel i815 chipset?
To be fair I should have mentioned the hardware entropy solutions that both Intel (i810, i815, etc) and AMD (76x boards) have available, but they are much smaller offerings in Intel and AMD's product line. Contrast this with VIA which is making the Nehemiah core a centerpiece of existing EPIA boards, like the M10k, and forthcoming boards like the M2.
I read the sample chapter and the table of contents, and this certainly looks like a very useful book for developers.
/dev/urandom. ... I wonder if this book is out on Safari yet.
The random number generation chapter is excellent. Many people overlook this necessity in cryptographic applications unaware that flaws introduced by insecurely random (i.e. predictable) enrtropy sources can render the best PKI, ciphers and authentication mechanisms crippled.
One of the reasons I tend to drool over VIA hardware is that their MiniITX EPIA systems have support for hardware entropy on the CPU via the Nehemiah core, which is also available for a wide variety of OEM/embedded applications.
This means you can use a highly secure entropy source (/dev/hw_random in linux for example) for all of your cryptographic applications, from GPG to ssh to the linux kernel itself (IPSEC). And best of all, you never have to worry about the entropy pool blocking, or reverting to less secure PRNG like
You have clearly missed my point that placing a file in a public place does not imply distribution (legally tested).
No, as I've stated before, this is not about simply placing a file in a public place. This is about unathorized distribution, aka, "uploading a song" to a RIAA contracted spider / peer.
Quit trying to change the subject.
we are talking about what happened in front of a US Federal Grand Jury.
Like I said previously, this is not about access, this is about actual distribution, i.e. uploading.
Howevevr you miss the point about single vs. multisourvce dosnloading. The process of switching sources is automatic.If you can't show me a session log, I'm sorry, you don't have the remotest bit of proof.
Agreed, which is why they are not using multi-source uploading at all. Not at all. Its all single source uploading from gnutella and kazaa. If they did target a multisource network, they would simply elect to obtain the full content from a single peer at a time.
The multisource upload capability in even peer file sharing implementation (aside from freenet, which is not p2p sharing) is driven by the client. If you have a modified RIAA client explicitly asking for full downloads from a single source, they can get the client to do so.
"Secure MD5 digest" is an oxymoron. Please read the literature.
I'm not going to discuss this further, but while MD5 is questionable as a secure digital signature / encryption challenge mechanism, it is still highly resistant to collision (on the order of 2^64 not considering file length as an identifying factor) which is suitably convincing in a court of law or federal grand jury as you mention, especially when you are dealing with known MD5's for multiple songs, all of which where sucessfully upload from the target peer.
Are you working for one of these companies? Is this why you are so defensive about the techniques?
No, i just find it annoying when serious weaknesses are dismissed out of hand. I have been working on open source peer networking software for many years, and would prefer that legal vulnerabilities are addressed on technical grounds rather than dismissed on legal assumption.
For example, achord and mix networks would provide a very strong layer of anonymity with regards to block sources in a multi-source download as well as caches of encrypted data (i.e. freenet style separation of key and data with onion style routing protection against traffic analysis and achord ensurance against requesting all blocks
from a single anonymous source.