Hello hackers,
I am new to FreeBSD but I am familiar with Unix like systems
in general and Linux in particular.
I am doing a project where-in I need to manipulate a few
things in the mbuf's of network stack (mainly in TCP) and
capture per packet statistics. Then the collated data has to
be
First one is in general abt the method to be followed, I
have the following ideas ... [snip]
Have you looked at netgraph(4) and ng_socket(4)?
--
FreeBSD Volunteer, http://people.freebsd.org/~jkoshy
___
freebsd-hackers@freebsd.org mailing list
On Thu, 3 Mar 2005, Saber Zrelli wrote:
Hi all ,
I'm runnig FreeBSD 5.3-RELEASE #0 on an IBM Thinkpad R50p ,
when I run some make install in the ports distribution.
I got the following message :
tornado root: WARNING: system temperature too high, shutting down soon!
After 2-3 secs the system shuts
On Thu, Mar 03, 2005 at 01:30:15AM +0100, Poul-Henning Kamp wrote:
In message [EMAIL PROTECTED], Roland Dowdeswell wri
tes:
Let's discuss a simple example and see how it works. Let's walk
through a user login, with /etc/passwd on GBDE and the filesystem
mounted with mtime.
These days,
In message [EMAIL PROTECTED], Bernd Walter writes:
No matter what disk you take - writes never have been atomic.
The major difference I see is that you get a read error back in
the disk failure case, while such a crypto failure produces more or
less random data without any error.
Mounting unclean
I think the original author expressed the following concern:
- without the GBDE, a failure to write meta-data for a file (say,
'atime' for /etc/passwd) will not result in an unusable system.
Whether it was written or not does not matter much: either way, the
links to actual file blocks remain
On Thu, Mar 03, 2005 at 01:18:45PM +0100, Poul-Henning Kamp wrote:
In message [EMAIL PROTECTED], Bernd Walter writes:
No matter what disk you take - writes never have been atomic.
The major difference I see is that you get a read error back in
the disk failure case, while such a crypto
Yes, but you still incur a lot of context switching overhead between the
1000 threads. Increasing the time quantum should give you better
throughput with a penalty to interactivity which isn't really an issue
if no one is running a graphical desktop.
???
I think...
-Original Message-
ALeine wrote:
Algebraic attacks on AES show that AES may indeed be broken sooner than
we would hope, at least according to the information at:
http://www.cryptosystem.net/aes/
Please stop referring to this website.
Sorry, but everybody in the field of cryptology, except Nicolas
Courtois, agree
On March 2, 2005 12:09 pm, Julian Elischer wrote:
NPTL?
New Pthreads Library from Library?
isn't that GPL'd?
Native Posix Threads Library
All I know about it is the name. :)
--
Freddie Cash, CCNT CCLPHelpdesk / Network Support Tech.
School District 73 (250) 377-HELP
On Sat, Feb 26, 2005 at 09:02:14AM -0800, ALeine wrote:
[EMAIL PROTECTED] wrote:
I did this as the first hack. It made the problem worse. I'll try
patching both umass.c and scsi_da.c maybe they will have some sort of
synergistic effect.
Adding DA_Q_NO_SYNC_CACHE in scsi_da.c in
On Mon, Feb 28, 2005, Julian Elischer wrote:
Ashwin Chandra wrote:
I wanted to get some clarification about the 4BSD scheduler. I am sort of
confused why there are two forms of scheduling, one done between processes
and
another done between threads in a process. The priority calculations
Alfred Perlstein wrote:
Can someone review this? I think 'u' is incorrectly
added to instead of assigned to. This causes the initial
calculation to be garage based and screws up displaying
poll information.
I'd like this to be MFC'd before 5.4 if possible.
Index: syscalls.c
Joseph,
Have you looked at netgraph(4) and ng_socket(4)?
Thanx for the reply. I looked into them now. But looks like
it will be an overkill for me. Let me give a little more
context of my problem. I need to evaluate a new congestion
control protocol (which has been implemented as an extension
[EMAIL PROTECTED] wrote:
In message [EMAIL PROTECTED], Bernd
Walter writes:
And how would you know that a restore from backup is required
for a damaged file?
100% true.
The trouble is that it would cost a lot in performance and a
doubling in metadata to protect yourself against this.
In message [EMAIL PROTECTED], ALeine writes:
Not necessarily, if one were to implement the ideas I proposed
I believe the performance could be kept at the same level as now.
I gave up on journalling myself because IMO it complicates
things a lot and the problem it solves is very very small.
The
In message: [EMAIL PROTECTED]
Joseph Koshy [EMAIL PROTECTED] writes:
: First one is in general abt the method to be followed, I
: have the following ideas ... [snip]
:
: Have you looked at netgraph(4) and ng_socket(4)?
Or bpf(4)?
Warner
In message [EMAIL PROTECTED], Thor Lancelot Simon writes:
No, it would not. What it _would_ take would be an abandonment of the
adamant position that your home-grown cryptosystem is superior to
simply encrypting the disk with 256-bit AES.
Where I come from home-grown is not derogative. All
In message [EMAIL PROTECTED], Thor Lancelot Simon writes:
I could not disagree more. When it comes to nonstandard homebrewed
cryptosystems foisted off on unsuspecting users with a bundle of
claims of algorithm strength that they're not competent to evaluate
for themselves, we do not need more
On 1109809815 seconds since the Beginning of the UNIX epoch
Poul-Henning Kamp wrote:
In message [EMAIL PROTECTED], Roland Dowdeswell wr
i
tes:
Let's discuss a simple example and see how it works. Let's walk
through a user login, with /etc/passwd on GBDE and the filesystem
mounted with mtime.
[EMAIL PROTECTED] wrote:
I gave up on journalling myself because IMO it complicates
things a lot and the problem it solves is very very small.
If only hardware manufacturers were to equip hard drives with
a mechanism to ensure atomic writes. A capacitor large enough
to hold enough energy to
In message [EMAIL PROTECTED], Roland Dowdeswell writes:
I chose CGD with AES256 for two reasons. First I wanted to compare
systems with comparable performance.
More computing sins are committed in the name of efficiency
(without necessarily achieving it) than for any other
Poul-Henning Kamp wrote:
I fully agree with you about the philosophical points, but not on
the implications.
I can not convince myself that encrypting a 40 GB disk sector by
sector using the same key, even if it is 256 bits, is a safe design.
You seem to belive otherwise.
And that's where it ends.
[EMAIL PROTECTED] wrote:
In message [EMAIL PROTECTED], Thor Lancelot Simon
writes:
Where I come from home-grown is not derogative. All
cryptosystems are by necessity home-grown for somebody somewhere.
I second that, standards do not come into existence out of thin
air and we might get to
In message [EMAIL PROTECTED], ALeine writes:
[EMAIL PROTECTED] wrote:
I gave up on journalling myself because IMO it complicates
things a lot and the problem it solves is very very small.
If only hardware manufacturers were to equip hard drives with
a mechanism to ensure atomic writes.
I
In message [EMAIL PROTECTED], Richard Coleman writes:
For instance, the NIST specification for AES and CCM mode (NIST Special
Publication 800-38C) specifically states that you must limit the number
of invocations of the block cipher (specifically AES) to 2^61. Now, I
realize that is an upper
For instance, the NIST specification for AES and CCM mode (NIST Special
Publication 800-38C) specifically states that you must limit the number
of invocations of the block cipher (specifically AES) to 2^61. Now, I
realize that is an upper bound. But even after removing several orders
of
On Thu, Mar 03, 2005 at 06:51:08PM +0100, Poul-Henning Kamp wrote:
In message [EMAIL PROTECTED], ALeine writes:
[EMAIL PROTECTED] wrote:
I gave up on journalling myself because IMO it complicates
things a lot and the problem it solves is very very small.
If only hardware manufacturers
In message [EMAIL PROTECTED], Thor Lancelot Simon writes:
It also uses MD5 in a way that I would characterize as not exactly
ordinary
The only role MD5 has is as a bit-blender. Any strength it may
add is just a bonus.
Indeed, the large number of algorithms
used in the keying and encryption
Again I was left out of the loop by a certain someone who is not
subscribed to [EMAIL PROTECTED], so I apologize for replying
indirectly.
[EMAIL PROTECTED] wrote:
In message [EMAIL PROTECTED],
Steven M. Bellovin writes:
I don't claim that there's a flaw. I do assert that that I
haven't
On 1109800339 seconds since the Beginning of the UNIX epoch
ALeine wrote:
Both Lucky Green and David Wagner has nodded vertical on GBDE.
I trust the professional opinions of both Lucky Green and David Wagner
at least an order of magnitute more than that of Roland Dowdeswell,
especially after
[EMAIL PROTECTED] wrote:
I can not encourage you enough to try it.
Don't let peole like Thor scare you away, progress happens when
people try to follow their ideas, even if told that they are fools by
people who (think they) know better.
Thor? Who is Thor? :- Seriously, this discussion is
In message [EMAIL PROTECTED], Perry E. Metzger writes:
There is a profession called cryptographer out there. They are the
folks who try out these new ideas, and they fill lots of conference
proceedings with their new ideas, including things like crypto modes
designed specifically for disk
[EMAIL PROTECTED] wrote:
Poul-Henning Kamp [EMAIL PROTECTED] writes:
We need more ideas and more people trying out ideas.
There is a profession called cryptographer out there. They are
the folks who try out these new ideas, and they fill lots of
conference proceedings with their new
Hey guys,
if we broke libc, and we cannot do anything at the prompt
/libexec/ld-elf.so.1: Shared object libc.so.5 not found..
what is the quick fix for this?
also what is the correct way of adding names to system calls in libc so instead
of doing a syscall(445), we can actually call it by
Kamal R. Prasad wrote:
--- Julian Elischer [EMAIL PROTECTED] wrote:
Kamal R. Prasad wrote:
--- Lucas Holt [EMAIL PROTECTED] wrote:
Wouldn't a multi threaded program potentially need
more cpu time than
vi?
No. That is not a given.
Multithreaded apps are
On Thu, 3 Mar 2005 12:02:50 -0800, Ashwin Chandra [EMAIL PROTECTED] wrote:
Hey guys,
if we broke libc, and we cannot do anything at the prompt
/libexec/ld-elf.so.1: Shared object libc.so.5 not found..
what is the quick fix for this?
libmap.conf(5), but a real solution is to recompile that file.
I must have missed this one before.
[EMAIL PROTECTED] wrote:
Most of this started when I disputed some of the wild claims that
PHK has made about the security of GBDE.
You have not disputed them, you have only confirmed the strengths of
GBDE and exposed the issue of atomic writes.
Let me
In message [EMAIL PROTECTED], Thor Lancelot Simon writes:
On Thu, Mar 03, 2005 at 08:25:18PM +0100, Poul-Henning Kamp wrote:
To quote David Hume, Never an ought from an is.
I'm Danish by birth so english is only my second language, so I
apologize for mangling it.
That users (who
are they? how
In message [EMAIL PROTECTED], Todd Vierling writes:
On Thu, 3 Mar 2005, Poul-Henning Kamp wrote:
At the time where I wrote GBDE, the best that was offered was CGD (and
similar) and users (not cryptographers!) didn't trust it
Could you back up this claim, insofar that users did not trust cgd?
In the last episode (Mar 03), Ashwin Chandra said:
if we broke libc, and we cannot do anything at the prompt
/libexec/ld-elf.so.1: Shared object libc.so.5 not found..
what is the quick fix for this?
Use the statically-linked binaries in /rescue/* to mount a remote
filesystem (or floppy or
In message [EMAIL PROTECTED], Perry E. Metzger writes:
There is a world out here that's called the IT industry.
Yes, there is. They routinely deploy bad security because they don't
get people who know what they are doing involved. See WEP, for
example, or a thousand other things.
Yes, it would
In message [EMAIL PROTECTED], Perry E. Metzger writes:
Poul-Henning Kamp [EMAIL PROTECTED] writes:
Don't let peole like Thor scare you away, progress happens when people
try to follow their ideas, even if told that they are fools by people
who (think they) know better.
They laughed at Fulton.
In message [EMAIL PROTECTED], Perry E. Metzger writes:
Poul-Henning Kamp [EMAIL PROTECTED] writes:
In message [EMAIL PROTECTED], Todd Vierling writes:
On Thu, 3 Mar 2005, Poul-Henning Kamp wrote:
At the time where I wrote GBDE, the best that was offered was CGD (and
similar) and users (not
In message [EMAIL PROTECTED], ALeine writes:
[EMAIL PROTECTED] wrote:
I can not encourage you enough to try it.
Don't let peole like Thor scare you away, progress happens when
people try to follow their ideas, even if told that they are fools by
people who (think they) know better.
Thor?
In message [EMAIL PROTECTED], Todd Vierling writes:
On Thu, 3 Mar 2005, Poul-Henning Kamp wrote:
And if CGD is _so_ officially approved as you say, then I can not
for the life of me understand how it can use the same key to generate
the IV and perform the encryption. At the very least two
[EMAIL PROTECTED] wrote:
You are mistaking people who design cryptographic algorithms
and those who design cryptographic systems which integrate those
algorithms into functional systems.
No, I am not. PHK invented new cryptographic modes for his work.
The fact that he does not
--
Message: 18
Date: Wed, 2 Mar 2005 13:15:49 -0800 (PST)
From: ALeine [EMAIL PROTECTED]
Subject: Re: FUD about CGD and GBDE
[EMAIL PROTECTED] wrote:
I gave up on journalling myself because IMO it complicates
things a lot and the problem it solves is
[EMAIL PROTECTED] wrote:
On Wed, Mar 02, 2005 at 04:33:16PM -0800, ALeine wrote:
[EMAIL PROTECTED] wrote:
It is _plainly_obvious_ that if you encrypt 2^30 sectors each
with a different 128 bit key then there are at most 2^158
different
ways to decrypt the entire disk. Period.
In message [EMAIL PROTECTED], Thor Lancelot Simon writes:
On Thu, Mar 03, 2005 at 10:15:55PM +0100, Poul-Henning Kamp wrote:
And if CGD is _so_ officially approved as you say, then I can not
for the life of me understand how it can use the same key to generate
the IV and perform the
[EMAIL PROTECTED] wrote:
Unfortunately, all these well-intentioned and very intelligent
people were wrong. The novel cryptographic modes they designed
to always be harder to break were in fact sometimes -- in fact,
in the case of PCBC, pretty much always -- easier to break than
the boring,
On 1109816230 seconds since the Beginning of the UNIX epoch
ALeine wrote:
No, you are wrong.
2^128*2^30 = 2^158
We are actually dealing with:
(2^128)^(2^30) = 2^(128*2^30) = 2^(2^37) = 2^137438953472
^--- notice the minor difference
It is a serial attack that
In message [EMAIL PROTECTED], Roland Dowdeswell writes:
Now, the key--key sector protects 32 disk
sectors which contain 32 * 512 * 8 = 131072 bits.
The key-key protect only a single sector-key, however, the actual
sectorsize may be bigger than 512 and I recommend that people use
the FFS fragment
In message [EMAIL PROTECTED], Perry E. Metzger writes:
I remember a certain talk at BSDCon where someone criticized the
design of the kernel RNG during the talk on it. He mentioned that the
person giving the presentation had stated a few inaccurate things,
such as claiming that there was a proof
In message [EMAIL PROTECTED], Perry E. Metzger writes:
MD5 was believed to be heavily understood in literature. It was
well established. Look at what happened to it.
Yup. And Roland made the algorithm you use for encrypting your disk
*pluggable*. That way, if AES is broken, you can replace it
I've spent the last hour trying to raise the maximum process data size
(ulimit -d). /etc/login.conf says unlimited, /boot/loader.conf has
nothing, and I can't find a sysctl that looks like it's doing
something nasty. I've RTFMd and found nothing. What am I missing?
Greg
--
See complete headers
On Fri, Mar 04, 2005 at 12:06:22PM +1030, Greg 'groggy' Lehey wrote:
I've spent the last hour trying to raise the maximum process data size
(ulimit -d). /etc/login.conf says unlimited, /boot/loader.conf has
nothing, and I can't find a sysctl that looks like it's doing
something nasty. I've
On Thursday, 3 March 2005 at 17:40:35 -0800, Brooks Davis wrote:
On Fri, Mar 04, 2005 at 12:06:22PM +1030, Greg 'groggy' Lehey wrote:
I've spent the last hour trying to raise the maximum process data size
(ulimit -d). /etc/login.conf says unlimited, /boot/loader.conf has
nothing, and I can't
--- Julian Elischer [EMAIL PROTECTED] wrote:
Kamal R. Prasad wrote:
--- Julian Elischer [EMAIL PROTECTED] wrote:
Kamal R. Prasad wrote:
--- Lucas Holt [EMAIL PROTECTED] wrote:
Wouldn't a multi threaded program potentially
need
more cpu time than
In message [EMAIL PROTECTED], Perry E. Metzger writes:
I also very strongly suggest that the biggest real threat you face
isn't someone cracking AES but key management issues. CGD is in some
sense largely a framework for letting you do all sorts of neat things
with key management in a disk
In message [EMAIL PROTECTED], Steven M. Bellovin writes:
You can subscribe to that list by sending to [EMAIL PROTECTED]
Feel free to post the link to my paper there.
For reasons of mental bandwidth I must decline to subscribe to more mailing
lists than I'm currently infected with, but that
M. Warner Losh wrote:
In message: [EMAIL PROTECTED]
Joseph Koshy [EMAIL PROTECTED] writes:
: First one is in general abt the method to be followed, I
: have the following ideas ... [snip]
:
: Have you looked at netgraph(4) and ng_socket(4)?
Or bpf(4)?
or KTR?
Warner
Kamal R. Prasad wrote:
--- Julian Elischer [EMAIL PROTECTED] wrote:
so how does that differ from what we have ... a
native pthreads library?
I just said if it was conformant with NPTL, thread and
process scheduling would co-exist.
in theory it does in FreeBSD's pthreads library.
(though it needs
In message [EMAIL PROTECTED], Perry E. Metzger writes:
My strong suggestion for you is that you adopt a similar approach --
build a good framework that, given good algorithms, will provide
security, and make it easy for users to change over if an algorithm
falls.
If you actually look at GBDE,
In message [EMAIL PROTECTED], Roland Dowdeswell writes:
The claim is made that there is at least O(2^256) work to crack a
disk and O(2^384) to crack the disk if the lock sectors are destroyed.
Roland, in particular when you get into big numbers you have to
pay attention to small details.
The
65 matches
Mail list logo
