«

Susan said

> Is there a way to post to the usenet such that my posts aren't
> traceable back to me ten years later? Is there some freeware that
> will "anonymize" my email address (I'm not worried about my first
> name, which is a nickname anyway but I want to anonymize my email
> address and IP).

I use COTSE (cotse.net).
URL: https://www.cotse.net/home.html
USENET: alt.cotse

I have XNEWS set up to post responses (like this) through their remailer.
It's totally painless and quite private.
https://www.cotse.net/home.html

I do this on a group by group basis. So some groups list me fake name and
valid IP. Others (like this group) get my other fake name (:-]) and no
IP.

"I" don't even know who I am anymore.

You can also use QuickSilver for free. But the COTSE remailer is less
hassle.

Joe Smith III


-=-
This message was sent via two or more anonymous remailing services.

"Al Klein" <> wrote in message
news:
> On Sat, 22 Jul 2006 21:16:12 GMT, Susan
> <> wrote:
>
> > On 20 Jul 2006 16:34:17 -0700,
> > wrote:
> > > Two click in Google Groups yields a lot of
> > > information and someone could decide to impose their
> > > moral code on you and give Livingston Enterprises a
> > > call. Go to Target and buy a prepaid cell phone with
> > > cash.
>
> > Do I know you?
> > I haven't been there for almost a decade.
> > How do you supposedly know this?
>
> I think he was just showing you that "anonymous" died a
> long time ago.

Especially when they don't munge their email addresses on usenet.

Ivor

"Susan" <> wrote in message
news:1w3v6avcmzou$.1rm64ow7e381e$.
> On Sat, 22 Jul 2006 18:03:40 -0400, Bill Kearney wrote:
> > > Please advise me
> > Get off the phone, get back to work and stop being a
> > homewrecker.
>
> Is this all you can offer to the technical discussion of
> securing a modicum of privacy in Internet voice over IP
> communications?

You are not entitled to privacy whilst using your employer's equipment and
bandwidth.

Ivor

On Sun, 23 Jul 2006 17:51:32 +0100, Ivor Jones wrote:

> You are not entitled to privacy whilst using your employer's equipment and
> bandwidth.

In line with the claims of its creators, Skype appears to encrypt or
otherwise scramble information that is transmitted over the Internet.
Although it is generally accepted that Skype is secure against casual
snooping, it is not clear how it would fare against sophisticated
attackers.

The security of any data sent over an encrypted connection depends upon
many factors, including the specific encryption algorithms used and how
encryption keys are chosen or exchanged (known as key management). Also of
critical importance is the protocol that employs the algorithms, and how
well both the algorithms and protocols are implemented. An analysis of the
packets sent between Skype clients indicates that a combination of
protocols appear to be used for actions such registering oneself on the
network, searching for other participants, or making a voice telephone
call.

Skype claims that its system employs RSAÿs encryption for key exchange and
256-bit AES as its bulk encryption algorithm. However, Skype does not
publish its key exchange algorithm or its over-the-wire protocol. Despite
repeated requests, Skype refuses to explain the underlying design of its
certificates, authentication system, or encryption implementation. It is
therefore impossible to validate the company's claims regarding encryption.
A poor implementation of the RSA algorithm could provide encryption, but no
actual security.

In order to avoid detection, many peer-to-peer applications, including
Skype, change the port that they use each time they start. Consequently,
there is no standard "Skype port" like there is a "SIP port" or "SMTP
port". In addition, Skype is particularly adept at port-hopping with the
aim of traversing enterprise firewalls. Entering via UDP, TCP, or even TCP
on port 80, Skype is usually very successful at passing typical firewalls.
Once inside, it then intentionally connects to other Skype clients and
remains connected, maintaining a ´virtual circuit¡. If one of those clients
happens to be infected, then the machines that connect to it can be
infected with no protection from the firewall. Moreover, because Skype has
the ability to port-hop, it is much harder to detect anomalous behavior or
configure network security devices to block the spread of the infection.

Like its file sharing predecessor Kazaa, Skype employs an overlay
peer-to-peer network. There are two types of nodes in this overlay network,
ordinary hosts and super nodes. An ordinary host is a Skype application
that can be used to place voice calls, send text messages, etc. A super
node is an ordinary hostÿs end-point on the Skype network, meaning that any
ordinary host must first connect to a super node and authenticate itself
with the Skype login server. Any node with a public IP address having
sufficient CPU, memory, and network bandwidth is a candidate to become a
super node - including machines that reside on enterprise networks. Because
Skype super nodes are created dynamically, and could conceivably consume as
much bandwidth as is available to them, enterprise IT managers consider
these super nodes a significant risk to the health of their network.

Privacy and Authenticity

When you initiate a Skype conversation, how sure are you that you are
actually reaching the user that you specified? Every Skype user has a
username and a password. It appears that the network is used by Skype to
perform username/password verification, but it isnÿt clear how this is
done. For example, hosts on the Skype network could relay the encrypted
username/password combination back to Skypeÿs servers for approval.
Alternatively, they could relay an unencrypted username/password
combination. If the Skype network is indeed involved in the communications,
several types of attacks may be possible:

A malicious Skype client may learn the username/password combination of
registered Skype users;

If a Skype user accesses the Skype network through a malicious Internet
Service Provider, the ISP may direct that userÿs Skype communications to
the malicious Skype node. Thus, it may be possible for a malicious ISP to
learn any of their userÿs Skype passwords;

A malicious node may fake a valid authentication, allowing a client to log
in with a particular Skype username even though the password for that
username is not known.

When using Skype as a voice communications system, its users can often rely
on identifying a person by the sound of their voice. This layer is absent,
however, if Skype is used only for text messaging and exchanging files.
These challenges are forcing carriers to look for accurate ways to detect
Skype (and other P2P protocols). In some cases the telecom Marketing
departments are highly interested in what percentage of their customers are
using Skype so that they can decide whether or not to launch their own
commercial VoIP service. In other cases, unpredictable bandwidth
consumption and security issues are concerning enterprise IT managers- the
customers of the telecom carrier. Many of these enterprise IT managers are
responding by requiring that the carrier actually block Skype traffic
before it hits their private networks.

Challenges In Detection of Skype Traffic

In general, effective Internet traffic detection and classification
requires three key elements:

1.Accuracy: the technique should have low false positive (identifying
other protocols as targeted protocol X);

2.Scalability: the technique must be able to process large traffic
volumes in the order of several hundred thousands to several million
connections at a time, with good accuracy, and yet not be computationally
expensive;

3.Robustness: traffic measurement in the middle of the network has to
deal with the effects of asymmetric routing (two directions of a connection
follow different paths), packet losses and reordering.

There are usually tradeoffs in terms of the level of accuracy, scalability
and robustness that can be achieved relative to the detection of any given
protocol or service.

One current classification practice consists of TCP/UDP port number
application identification using known TCP/UDP port numbers to identify
traffic flows. This method is highly scalable since only the TCP/UDP port
numbers must be recorded to identify a particular application. It is also
highly robust since a single packet is sufficient to make a successful
identification. Unfortunately port number-based identification is
increasingly inaccurate primarily due to the fact that P2P networks tend to
intentionally disguise their generated traffic in order to circumvent
filtering firewalls (as well as legal issues associated with organizations
like the Recording Industry Association of America). Most P2P networks now
operate on top of custom-designed proprietary protocols and their clients
can easily operate on any port number - even HTTPÿs port 80, making
port-based detection schemes incapable of accurate and robust
classification of Internet protocols.

To overcome the issues with port-based detection, a new technique has
emerged based on payload-signature methods. Using this technique,that
processes packet payloads for patterns or signatures that univocally
identify any given protocol. One challenge facing payload-signature
techniques on telecom networks is the high speed at which such pattern
matching algorithms must be executed, e.g. 2.5Gbps (OC4 and above. It is
therefore critical to design algorithms that can efficiently perform
pattern matching while simultaneously dealing with memory and CPU
limitations. Another key challenge is the lack of openly available,
reliable protocol specifications. This is partially due to developmental
history and partially a result of the proprietary nature of many protocols.
For example, most P2P protocols are both proprietary and constantly
evolving. Some of these (Gnutella for instance) provide some documentation,
but it is often incomplete, or not up-to-date. To make matters worse, there
are various implementations of Gnutella clients, some of which do not
comply with the specifications in the documentation (raising potential
inter-operability issues). For application detection and classification to
be accurate, it is important to identify signatures that span all the
variants (or at least the dominantly used ones). However, it is
increasingly common to see new applications (such as Skype or GCN)
employing 128-bit or 256-bit encryption techniques to defend the privacy of
the information exchanged between their users. As a consequence, the
payload-signature method fails when traffic is encrypted, because the
signatures in the packet payload are scrambled by the encryption.

Skype offers a combination of challenges that make it notoriously difficult
to detect with scalable, accurate algorithms:

The Skype agent does not run on any standard source port. Skype
randomly selects a source port for the agent to run on, then communicates
via either TCP or UDP, or both. The choice of the protocol that Skype uses
depends on whether the agent is behind a proxy/NAT or has a public IP
address. The destination IP addresses are not the same every time Skype
runs, and the destination port numbers are also not standard.

All communication via Skype is encrypted. This also means that phone
numbers called (SkypeOut) or other data are also encrypted. In many cases,
there is no direct communication between end users in Skype. All
communication passes through intermediate nodes, and these nodes may be
different for every call.

Skype is a peer-to-peer protocol, which means that the peers (IP
addresses) to which a Skype agent connects are many and the network is very
dynamic, so these peers (and thus their IP addresses) keep changing.

Skype provides voice, chat, file transfer and video services. It
appears that all of these services are passed together, making it difficult
to separate out voice, from chat, from video, etc.

To accurately detect and classify these unfriendly applications, it is
necessary to provide a systematic methodology that overcomes the lack of
well-known port numbers or user payload signatures. Instead, any new
methodology should analyze flow connections at the transport layer (Layer
4) to extract and profile key features from the packet streams processed.
Such a method could be referred to as ´classification in the dark¡.

"Susan" <> wrote in message
news:1w3v6avcmzou$.1rm64ow7e381e$... .
> On Sat, 22 Jul 2006 18:03:40 -0400, Bill Kearney wrote:
> >> Please advise me
> > Get off the phone, get back to work and stop being a homewrecker.
>
> Is this all you can offer to the technical discussion of securing a
modicum
> of privacy in Internet voice over IP communications?

Yes. Modicum of privacy is bullshit. You're expecting to abuse your
employer's time and network so you can engage in a clandestine relationship.
Wake up, and get back to work before you get fired and/or ruin the lives of
everyone unfortunate enough to be tangled up in your mess.

"Sue" <> wrote in message
news:
> On Sun, 23 Jul 2006 17:51:32 +0100, Ivor Jones wrote:
>
> > You are not entitled to privacy whilst using your
> > employer's equipment and bandwidth.
>
> In line with the claims of its creators, Skype appears to
> encrypt or otherwise scramble information that is
> transmitted over the Internet. Although it is generally
> accepted that Skype is secure against casual snooping, it
> is not clear how it would fare against sophisticated
> attackers.

[snip]

Irrelevant.

You are not entitled to privacy whilst using your employer's equipment and
bandwidth.

Ivor

In message <> "Ivor Jones"
<> wrote:

>"Sue" <> wrote in message
>news:
>> On Sun, 23 Jul 2006 17:51:32 +0100, Ivor Jones wrote:
>>
>> > You are not entitled to privacy whilst using your
>> > employer's equipment and bandwidth.
>>
>> In line with the claims of its creators, Skype appears to
>> encrypt or otherwise scramble information that is
>> transmitted over the Internet. Although it is generally
>> accepted that Skype is secure against casual snooping, it
>> is not clear how it would fare against sophisticated
>> attackers.
>
>[snip]
>
>Irrelevant.
>
>You are not entitled to privacy whilst using your employer's equipment and
>bandwidth.

That really depends on where you live. You may not, and if not, I do
feel sorry for you.

--
"These, and other cliches will be available to you all for one more
day of training, with me"
-- Jack O'Neill

"DevilsPGD" <> wrote in message
news:
> In message <> "Ivor Jones"
> <> wrote:

[snip]

> > You are not entitled to privacy whilst using your
> > employer's equipment and bandwidth.
>
> That really depends on where you live. You may not, and
> if not, I do feel sorry for you.

It depends on nothing. Your employer is paying for the equipment and
bandwidth; what makes you think you are entitled to any degree of privacy
whatever whilst using it for purposes unrelated to your employment..?

I don't need you to feel sorry for me, I do not consider the above to be
unfair. If you want to feel sorry for someone, do so for those who are
having to pay people while they aren't working.

Ivor

In message <> "Ivor Jones"
<> wrote:

>"DevilsPGD" <> wrote in message
>news:
>> In message <> "Ivor Jones"
>> <> wrote:
>
>[snip]
>
>> > You are not entitled to privacy whilst using your
>> > employer's equipment and bandwidth.
>>
>> That really depends on where you live. You may not, and
>> if not, I do feel sorry for you.
>
>It depends on nothing.

Well, the law in many jurisdictions would not agree. Regardless of who
paid for the equipment, the user may still have rights.

>Your employer is paying for the equipment and
>bandwidth; what makes you think you are entitled to any degree of privacy
>whatever whilst using it for purposes unrelated to your employment..?

Well, my employee handbook specifically states that during my lunch,
break, before and after work, and during other appropriate times (as
determined by my immediate supervisor) I may use company phones for
non-billable calls, and use the company PC for personal activities, as
long as those activities do not interfere with corporate activities.

We're also allowed to use the chairs to sit on during our breaks, the
lights to read a book during our breaks, the filtered and air
conditioned air to breath during our off hours.

>I don't need you to feel sorry for me, I do not consider the above to be
>unfair. If you want to feel sorry for someone, do so for those who are
>having to pay people while they aren't working.

*shrugs* I have an employer that realizes that happy employees are
productive employees. My employer shut down early last Friday to take
the entire group out on the lake, including supplying food and drink.

In December, the whole company is being flown to Vegas for a vacation.

This weekend, the entire technical support staff volunteered (not "was
encouraged to volunteer because otherwise we'd lose our jobs", but
honest-to-god offered) to come in and get us caught up because we're
backlogged.

It trickles down -- You treat me like a human, with respect, and let me
enjoy my work, I'll go above and beyond as well.

Counter that with my previous employer, call center position who one day
decided that even if you're late leaving for a break you have to be back
on time. I went to my manager and asked if we were supposed to place
the customer on hold when our breaks start, transfer the call back into
the queue, or hang up on them -- If an employer pushes, the employees
push back and in the end, all it does is hurt the customer.

As I said, if your employer treats you like a liability rather then an
asset, I feel sorry for you.

--
Our enemies are innovative and resourceful...They never
stop thinking about new ways to harm our country and
our people, and neither do we.
-- George W. Bush 08/05/2004

"DevilsPGD" <> wrote in message
news:
> In message <> "Ivor Jones"
> <> wrote:
>
> > "DevilsPGD" <> wrote in
> > message news:
> > > In message <> "Ivor
> > > Jones" <> wrote:
> >
> > [snip]
> >
> > > > You are not entitled to privacy whilst using your
> > > > employer's equipment and bandwidth.
> > >
> > > That really depends on where you live. You may not,
> > > and if not, I do feel sorry for you.
> >
> > It depends on nothing.
>
> Well, the law in many jurisdictions would not agree.
> Regardless of who paid for the equipment, the user may
> still have rights.

To steal bandwidth..? Hmm, ok.

> > Your employer is paying for the equipment and
> > bandwidth; what makes you think you are entitled to any
> > degree of privacy whatever whilst using it for purposes
> > unrelated to your employment..?
>
> Well, my employee handbook specifically states that
> during my lunch, break, before and after work, and during
> other appropriate times (as determined by my immediate
> supervisor) I may use company phones for non-billable
> calls, and use the company PC for personal activities, as
> long as those activities do not interfere with corporate
> activities.

Well good for you, but don't assume that everyone else worldwide has those
rights.

By the way, who do you think is paying for all this..? Ask your customers
if they're happy to fund your off-duty activities.


Ivor