Sponsored Content
Full Discussion: Bitys disapperead
Contact Us Post Here to Contact Site Administrators and Moderators Bitys disapperead Post 302961275 by giuliangiuseppe on Thursday 26th of November 2015 07:18:44 AM
Old 11-26-2015
Bits vanished (last login less than 6 months ago)

Dear All,
I was wondering how is possible that suddenlty all my bits credit are disapperead.
I am sure I had a bigger amount of bits last time (last time was definetly less than 6 months ago..).
Well I can't figured out what happened.

Thanks

Giuliano

Last edited by giuliangiuseppe; 11-26-2015 at 09:31 AM..
 
IPSEC_RANBITS(8)						  [FIXME: manual]						  IPSEC_RANBITS(8)

NAME
ipsec_ranbits - generate random bits in ASCII form SYNOPSIS
ipsec ranbits [--quick] [--continuous] [--bytes] nbits DESCRIPTION
Ranbits obtains nbits (rounded up to the nearest byte) high-quality random bits from random(4), and emits them on standard output as an ASCII string. The default output format is datatot(3) h format: lowercase hexadecimal with a 0x prefix and an underscore every 32 bits. The --quick option produces quick-and-dirty random bits: instead of using the high-quality random bits from /dev/random, which may take some time to supply the necessary bits if nbits is large, ranbits uses /dev/urandom, which yields prompt results but lower-quality randomness. The --continuous option uses datatot(3) x output format, like h but without the underscores. The --bytes option causes nbits to be interpreted as a byte count rather than a bit count. FILES
/dev/random, /dev/urandom SEE ALSO
ipsec_datatot(3), random(4) HISTORY
Written for the Linux FreeS/WAN project <http://www.freeswan.org> by Henry Spencer. BUGS
There is an internal limit on nbits, currently 20000. Without --quick, ranbits's run time is difficult to predict. A request for a large number of bits, at a time when the system's entropy pool is low on randomness, may take quite a while to satisfy. Though not a bug of ranbits, the direct use of /dev/hw_random, the Linux hardware random number generator is not supported because it can produce very non-random data. To properly use /dev/hw_random, the rngd daemon should be used to read from /dev/hw_random and write to /dev/random, while performing a FIPS test on the hardware random read. No changes to Openswan are required for this support - just a running rngd. [FIXME: source] 10/06/2010 IPSEC_RANBITS(8)
All times are GMT -4. The time now is 05:47 AM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy