Obsure doesn't mean hidden. It means unclear.
A key is hidden, completely out of the reach of an attacker (if you've got it right!)
and in a good system it takes a long time for them to guess or calculate it.
An obsure system is available to an attacker but just not immediately clear. It is
just a matter of time until it is understood and therefore compromised.
It could be possible to have a very obsure system which could take longer to
understand than the key discovery time for a hidden system.
So we agree on 'security by obscurity doesn't work' is just FUD.
So we agree on 'security by obscurity doesn't work' is just FUD.
Sorry this is getting a bit [OT] from TCP/IP stacks
QuoteSo we agree on 'security by obscurity doesn't work' is just FUD.
I wouldn't say we agree on that. If resources are limited and the
defender has a very large risk appetite and little to lose then there
is no point in boiling the ocean.
What we do agree on is the vast majority of security by obscurity
techniques are many orders of magnitude quicker to compromise
than modern good quality mathematically proven crypto system.
[Many systems (rfid tags, debit cards, SIM cards, etc) use secret encryption/hashing algorithms to keep their data safe.
The ethernet hardware normally handles the lower layers so a embedded client just sending data over a udp socket could do this without a stack `par-say`and just a few lines of code to set an IP address and fill the transmit buffer.
The ethernet hardware normally handles the lower layers so a embedded client just sending data over a udp socket could do this without a stack `par-say`and just a few lines of code to set an IP address and fill the transmit buffer.
Also if your implementing just a client you wont be hacked because there is nothing to hack, if however you implementing a TCP server and controlling say a door lock then security may be a different matter and all the above comments are valid.
The ethernet hardware normally handles the lower layers so a embedded client just sending data over a udp socket could do this without a stack `par-say`and just a few lines of code to set an IP address and fill the transmit buffer.
Broken by design! A fully agree with dfmischler. You also need an ARP cache with timeouts in case the MAC address of the other side changes. Otherwise the device would have to be power cycled.
Broken by design! A fully agree with dfmischler. You also need an ARP cache with timeouts in case the MAC address of the other side changes. Otherwise the device would have to be power cycled.That is if you want to go the IP route. If you want to go the minimalistic route you can define your own packet structure and use the MAC address to tell where a packet should go. Dumb switches (IOW most of the SOHO switches) don't look further than the MAC addressess anyway. The downside is that this kind of traffic can't be routed over internet (or you'd need to develop a bridge).
The user doesn't need to be bothered with IP adresses. You can use all kinds of discovery mechanisms like a lot of network attached devices employ without the device needing an IP address. Most configuration software comes up with a list of devices it found (usually one) and asks which one the user wants to configure or use. Most users (even field engineers) are completely lost when confronted with having to fill in an IP address.
With libpcap its pretty easy to send and receive your own packets onto the network card. I've used Uip in the past and I tested/prototyped the network side of the software on a PC. My embedded environment behaved much like a virtual machine where my Uip device had it's own MAC adress inside Windows.
Only on consumer SOHO routers DHCP is enabled by default but on professional hardware it most certainly is not. For example Microsoft's crappy DNS/DHCP server simply shuts down when it sees another DHCP server on the network causing all kinds of unwanted effects. In general you don't want multiple DHCP servers on the same network. And then there is lots of other network connected hardware like printers, scanners, etc.