search for: 56bit

I work for a company that builds an appliance based on FreeBSD (4.X) and we've just had our first question come up about exporting the appliance out of the US (specifically the EU). Since FreeBSD uses OpenSSL/OpenSSH, I'm under the impression that we need to gut out anything higher than 56bit (3DES/etc) crypto out of it. I would really appreciate it if someone could point me in the right direction on this :) -Tom

...t (dropped 0, overlimits 0 requeues 0) rate 29728bit 5pps backlog 0b 42p requeues 0 lended: 205 borrowed: 0 giants: 0 tokens: -141972 ctokens: -141972 class htb 11:1 root rate 10000Kbit ceil 10000Kbit burst 6600b cburst 6600b Sent 129540 bytes 205 pkt (dropped 0, overlimits 0 requeues 0) rate 56bit 0pps backlog 0b 0p requeues 0 lended: 0 borrowed: 0 giants: 0 tokens: 3953 ctokens: 3953 class htb 11:21 parent 11:1 leaf 21: prio 5 rate 1024Kbit ceil 1024Kbit burst 2112b cburst 2112b Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 lended: 0 b...

Hi, I have a server and ten clients in a Gigabit network. The server has 125mbps network bandwidth. I want that the server has 40Mbps bandwidth reserved for client 1 (IP 192.168.5.141), and the rest bandwidth is for all other clients. My script looks like this (I use IFB for incoming traffic): #!/bin/bash export TC="/sbin/tc" $TC qdisc add dev ifb0 root handle 1: htb default 30

Dear all, First, sorry for my bad English .. To night one of my client is the victim of UDP attack from internet. It''s tons of UDP packets from internet with destination to port 80. But when I look at class of that victim client, the actual class rate is over than configured rate class. Below is my screen capture. You can see at class 1:913 which have actual rate 105136bit while

...y script. Sometimes ago I found >> this situation but I forgot to capture the screen and the traffic is UDP too >> (maybe from torrent-like client) > >Yes it is normal! > >The rate tables that tc use normally have an 8 byte steps, so it is >possible for up to a 56bit/s error per packet and you have 300 pps. > >There was a small patch submitted for tc to make the error fall on the >underrate rather than overrate side, but I think it got lost in the >middle of the long ATM overhead patch thread on netdev. > >Andy.

This was posted not too long ago on sci.crypt... Enjoy... I think the most relevant information is near the top, but it''s all quite good... :-) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- There is no intrinsic difference between algorithm and data, the same information can be viewed as data in one context and as algorithm in another. Why then do so many people claim that encryption algorithms