What I meant to say is that until now, Cryptix implements the 1.1 version of JCE. This version was never offcially released by Sun. Any decent JCE provider should implement the 1.2 version of the JCE. Luckily Cryptix now seems to to this, after a long period of little activity.
Well, I am sure the competition has disassemblers, debuggers, emulators and logic analyzers to dissect the interface. it is a myth that a binary driver protects your hardware interface.
Why should a hardware company protect the driver? If you make a quality, high performance driver, more people would want to buy the hardware. If you make a lousy, slow driver, not many people would buy the hardware to use on Linux.
So you your company should go for the best possible driver, to increase hardware sales.
If that means GPL'ing the driver, you can also benefit from the expertise of a lot of developers.
Most wireless keyboards, like garage door openers, have their own unique codes and frequencies built in to them so one cannot interface with another in the same way.
You are a bit to confident:
Available channels for these type of devices are very limited, so they have to share.
Cheap mice and keyboard don't do unique numbers, because it makes the devices more expensive: you have to pair devices during manufacturing and packaging, for example.
Well, hardly convincing. Just because some firewalls products do not behave according to your expectations, you go for a hack that was invented for IPv4 and makes no sense for IPv6. I bet some NAT implementations also are vulnerable. Assuming that NAT is fail-safe is dangerous.
Furthermore, I would be very surprised if NAT for IPv6 is or will be implemented, because there is no need and it will break IPSEC. Another poster also mentioned P2P, which requires connectivity between any two peers, which NAT makes very difficult.
When I started using NAT rather than a computer directly interfaced to an ADSL modem, the number of attacks dropped from about a dozen a day to one or two a month
You are using NAT for outgoing connections. If you do not specify redirect rules for incoming connections, you effectively have very strict firewall rules for incoming traffic.
My IPv6 traffic is filtered by my OpenBSD machine, which also does the IPv6 in IPv4 tunneling to my provider xs4all.nl.
It's just the way IPv6 addresses are allocated. By default, the host part of an address is 64 bits. I can use 4 bits to make subnets. Do not worry about overuse, there remain about 2^60 of these address blocks.
To make auto config possible, you need quite a big host part, at least 48 bits, the size of a ethernet MAC address. Probably they choose 64 bits to allow for larger MAC addresses.
You can read more about IPv6 and its address allocation policies here.
Does not the current IPv6 address allocation standard specify using your MAC address as the suffix portion of the IPv6 address?
This is just the default address. You can assign multiple addresses to an interface or remove the default if you want. But the nice thing is that using default addresses client machines require no network configuration at all.
unless you use IPv6 NAT, of course
Using NAT for IPv6 is silly. Why use NAT if you have plenty addresses? I personally have 2^68 addresses allocated to me by my provider. All my machines are reachable directly via IPv6, no redirects of whatever.
It seems I was thinking GPS too much. GPS uses propagation delays. They are using signal strength....
But randomizing the signal strength should fool the system too, however.
Easy to beat: introduce (random) delays
on
WiFi Triangulation
·
· Score: 1
The system uses delays to measure distance.
Once you introduce random delays, measuring the delays will not give a clue. Of course these delays should be really random (pseudo random is not enough), which may be harder than you think.
Another way of fooling the system is using constant delays per base station: your wireless device can convince the tracking system you are at a position you choose yourself.
Shouldn't we improve bus speed, data access speeds, etc etc first? After all, the bottleneck is not the processor anymore...
No.
Because the whole point is preventing memory access. High bandwidth busses are very expensive. If you have a lot of registers, you can avoid memory accesses, making instructions run at full speed.
The best way to reduce the impact of a bottleneck is not making the bottleneck wider. It is making sure your data doesn't need to travel through the bottleneck.
After that, it doesn't hurt to make the bus bandwidth bigger.
iSync only wants to talk to Apple server
on
iSync Beta Released
·
· Score: 5, Informative
I found out that
iSync does not use WebDAV, but a different protocol (at least for registering).
iSync contacts the server using https. The server is authenticated properly. I tried to fool iSync like I did with Backup but that didn't work, because iSync does not accept the server certificate.
So at first look, iSync security is better done than Backup, making it hard to use another server, like can be done with iCal or Backup.
Both work fine. I can mount the disk using "Connect to Server" and I can use it as iCal publish URL too. I am using the apache from OpenBSD 3.1, which is version 1.3.24, with a small number of OpenBSD specific patches.
Here's an extract of a httpd.conf file on a OpenBSD apache that serves WebDAV disks fine. Should work the same on Linux server, but I did not try that.
Load the module: LoadModule digest_auth_module/usr/lib/apache/modules/mod_auth_digest.so
And here's the directory entry: <Directory/home/dothome/dav> DAV On AuthType Digest AuthName "DotHome" AuthDigestFile/var/www/conf/passwd AllowOverride None Options None </Directory> <Directory/home/dothome/dav/joe> <Limit PUT POST DELETE PROPFIND PROPPATCH MKCOL COPY MOVE LOCK UNLOCK> Require user joe </Limit> </Directory>
Create the passwd entry with htdigest, using the realm DotHome.
Since 10.0 it is Command-V (V was the public beta). The information in the daemon news article is quite old. Jaguar seems a lot less verbose. It does not say anything about DMA transfers for disk or CD. Which of course doesn't mean it does not do DMA.
The info on the difference between a secure hash and a signature may be correct, but if you look in the archive, you'll find out that the code is signed:
At best this analogy is provoked by ignorance of laws, be it electrical or not. I currently own mass amounts of electricity, stored in a proper way. I can point to it (loom at me, I just did!
I can try to touch it, but that may be dangerous. It is properly isolated. It may need renewal once in a while, but so does my food if I keep it too long in the fridge.
Apart from that I am happy with my batteries and I would love to sell you some intellectual property some day, this sample being free.
Slashdot Mirror
- Every programs contains bugs.
- Every program contains redundancies and so can be made smaller without changing behavior.
Therefore the empty program is redundant but still buggy.What I meant to say is that until now, Cryptix implements the 1.1 version of JCE. This version was never offcially released by Sun. Any decent JCE provider should implement the 1.2 version of the JCE. Luckily Cryptix now seems to to this, after a long period of little activity.
Cryptix is quite late with JCE compatibility.
- Go to a phone shop (or supermarket, or toy store, anywhere)
- Buy a prepaid phone.
- Make your call. Do not forget to switch off sending caller ID.
Here in the Netherlands (and the rest of Europe) a very large part (>50%) of mobile phones are prepaid. No subscription or ID required.If you are under 18, you cannot get a subscription, so you'll have to use a prepaid phone, or convince your parents to get a subscription for you.
While interesting, the article describes a vulnerability that already has been fixed.
I (very politely) stated an issue you have to consider when making a business decision. I did not say: you have to use GPL because I say so.
Well, I am sure the competition has disassemblers, debuggers, emulators and logic analyzers to dissect the interface. it is a myth that a binary driver protects your hardware interface.
So you your company should go for the best possible driver, to increase hardware sales. If that means GPL'ing the driver, you can also benefit from the expertise of a lot of developers.
Don't you know that any posting should have at least one spelling error too be accepted as genuine /.?
You are a bit to confident:
- Available channels for these type of devices are very limited, so they have to share.
- Cheap mice and keyboard don't do unique numbers, because it makes the devices more expensive: you have to pair devices during manufacturing and packaging, for example.
- Garage doors openers have a notouriously bad track record on security. Ross Anderson's "Security Engineering" contains lots of real life examples.
So the story might have been true very well.This site explains it all: the PCjr was an ill-fated attempt at the consumer market by IBM.
Furthermore, I would be very surprised if NAT for IPv6 is or will be implemented, because there is no need and it will break IPSEC. Another poster also mentioned P2P, which requires connectivity between any two peers, which NAT makes very difficult.
You are using NAT for outgoing connections. If you do not specify redirect rules for incoming connections, you effectively have very strict firewall rules for incoming traffic.
My IPv6 traffic is filtered by my OpenBSD machine, which also does the IPv6 in IPv4 tunneling to my provider xs4all.nl.
To make auto config possible, you need quite a big host part, at least 48 bits, the size of a ethernet MAC address. Probably they choose 64 bits to allow for larger MAC addresses.
You can read more about IPv6 and its address allocation policies here.
Does not the current IPv6 address allocation standard specify using your MAC address as the suffix portion of the IPv6 address?
This is just the default address. You can assign multiple addresses to an interface or remove the default if you want. But the nice thing is that using default addresses client machines require no network configuration at all.
unless you use IPv6 NAT, of course
Using NAT for IPv6 is silly. Why use NAT if you have plenty addresses? I personally have 2^68 addresses allocated to me by my provider. All my machines are reachable directly via IPv6, no redirects of whatever.
But randomizing the signal strength should fool the system too, however.
Once you introduce random delays, measuring the delays will not give a clue. Of course these delays should be really random (pseudo random is not enough), which may be harder than you think.
Another way of fooling the system is using constant delays per base station: your wireless device can convince the tracking system you are at a position you choose yourself.
No. Because the whole point is preventing memory access. High bandwidth busses are very expensive. If you have a lot of registers, you can avoid memory accesses, making instructions run at full speed.
The best way to reduce the impact of a bottleneck is not making the bottleneck wider. It is making sure your data doesn't need to travel through the bottleneck.
After that, it doesn't hurt to make the bus bandwidth bigger.
- iSync does not use WebDAV, but a different protocol (at least for registering).
- iSync contacts the server using https. The server is authenticated properly. I tried to fool iSync like I did with Backup but that didn't work, because iSync does not accept the server certificate.
So at first look, iSync security is better done than Backup, making it hard to use another server, like can be done with iCal or Backup.Darwin is a BSD derivative. As the GNU/Linux FAQ states, the GNU/ thing does not apply to BSD derived work.
So no GNU/Darwin. Just Darwin.
Both work fine. I can mount the disk using "Connect to Server" and I can use it as iCal publish URL too. I am using the apache from OpenBSD 3.1, which is version 1.3.24, with a small number of OpenBSD specific patches.
Here's an extract of a httpd.conf file on a OpenBSD apache that serves WebDAV disks fine. Should work the same on Linux server, but I did not try that.
/usr/lib/apache/modules/mod_auth_digest.so
/home/dothome/dav> /var/www/conf/passwd /home/dothome/dav/joe>
Load the module:
LoadModule digest_auth_module
And here's the directory entry:
<Directory
DAV On
AuthType Digest
AuthName "DotHome"
AuthDigestFile
AllowOverride None
Options None
</Directory>
<Directory
<Limit PUT POST DELETE PROPFIND PROPPATCH MKCOL COPY MOVE LOCK UNLOCK>
Require user joe
</Limit>
</Directory>
Create the passwd entry with htdigest, using the realm DotHome.
Since 10.0 it is Command-V (V was the public beta). The information in the daemon news article is quite old. Jaguar seems a lot less verbose. It does not say anything about DMA transfers for disk or CD. Which of course doesn't mean it does not do DMA.
The info on the difference between a secure hash and a signature may be correct, but if you look in the archive, you'll find out that the code is signed:
b le /openssh-3.4p1.tar.gz.sig
ftp://ftp.openbsd.org/pub/OpenBSD/OpenSSH/porta
This file contains a GnuPG sig, and the trojaned tarball fails verification.
At best this analogy is provoked by ignorance of laws, be it electrical or not. I currently own mass amounts of electricity, stored in a proper way. I can point to it (loom at me, I just did!
I can try to touch it, but that may be dangerous. It is properly isolated. It may need renewal once in a while, but so does my food if I keep it too long in the fridge.
Apart from that I am happy with my batteries and I would love to sell you some intellectual property some day, this sample being free.