search for: drng

...p(scal*(log(x)-log(xmid)))), function(mCall, data, LHS) { #browser() xy <- sortedXyData(mCall[["x"]], LHS, data) if (nrow(xy) < 5) { stop("too few distinct input values to fit a four-parameter logistic") } rng <- range(xy$y) drng <- diff(rng) B <- rng[2] + 0.001 A <- rng[1] - 0.001 xy$prop <- log((B-xy$y)/(xy$y-A+0.001)) #(xy$y - rng[1] + 0.05 * drng)/(1.1 * drng) ir <- as.vector(coef(lm(prop ~ log(x), data = xy))) scal <- ir[2] xmid <- exp(-ir[1]/ir[2]) #pars <- as.ve...

...Nope, I do not think that this is true: - /dev/random returns one byte for one byte of entropy received, but it has a lower limit of 64 bits - getrandom behaves like /dev/urandom (i.e. nonblocking) except during boot where it waits until the RNG has collected 128 bits before operating like a DRNG that is seeded once in a while when entropy comes in. Ciao Stephan

...Nope, I do not think that this is true: - /dev/random returns one byte for one byte of entropy received, but it has a lower limit of 64 bits - getrandom behaves like /dev/urandom (i.e. nonblocking) except during boot where it waits until the RNG has collected 128 bits before operating like a DRNG that is seeded once in a while when entropy comes in. Ciao Stephan

We've been trying unsuccessfully to connect our Meridian Option 81C to a TE110P via PRI. We've followed the directions in asterisk-meridian-a1.pdf (link on http://www.voip-info.org/wiki/view/Asterisk+legacy+integration), but it doesn't seem to work on our 81C (even though many, many users report it works very well on Option 11's). Has anyone had any success in getting the above

...is true: > > - /dev/random returns one byte for one byte of entropy received, but > it has a lower limit of 64 bits > > - getrandom behaves like /dev/urandom (i.e. nonblocking) except > during boot where it waits until the RNG has collected 128 bits > before operating like a DRNG that is seeded once in a while when > entropy comes in. > > > Ciao > Stephan I don't follow. Assuming you are correct and this is the issue, then reading 128 bits (16 bytes) from /dev/random should "exhaust the supply" and then both reads from /dev/random and calling...

...NO OABS INST IDC NO DCNO 0 * NDNO 0 DEXT NO ANTK SIGO STD ICIS YES TIMR ICF 512 OGF 512 EOD 13952 NRD 10112 DDL 70 ODT 4096 RGV 640 GRD 896 SFB 3 NBS 2048 NBL 4096 IENB 5 TFD 0 VSS 0 VGD 6 DRNG NO CDR NO VRAT NO MUS NO FRL 0 0 FRL 1 0 FRL 2 0 FRL 3 0 FRL 4 0 FRL 5 0 FRL 6 0 FRL 7 0 OHQ NO OHQT 00 CBQ NO AUTH NO TDET NO TTBL 0 ATAN NO PLEV 2 ALRM NO ART 0 SGRP 0 AACR NO DES VERSA TN 101 01 TYPE TIE CDEN SD CUST 0 TRK PRI PDCA 1 PC...

On Fri, Jul 29, 2016 at 7:40 AM, Stephan Mueller <smueller at chronox.de> wrote: > And finally, you have a coding error that is very very common but fatal when > reading from /dev/random: you do not account for short reads which implies > that your loop continues even in the case of short reads. > > Fix your code with something like the following: > int read_random(char

On Fri, Jul 29, 2016 at 7:40 AM, Stephan Mueller <smueller at chronox.de> wrote: > And finally, you have a coding error that is very very common but fatal when > reading from /dev/random: you do not account for short reads which implies > that your loop continues even in the case of short reads. > > Fix your code with something like the following: > int read_random(char

...ev/random returns one byte for one byte of entropy received, but > > it has a lower limit of 64 bits > > > > - getrandom behaves like /dev/urandom (i.e. nonblocking) except > > during boot where it waits until the RNG has collected 128 bits > > before operating like a DRNG that is seeded once in a while when > > entropy comes in. > > > > > > Ciao > > Stephan > > I don't follow. Assuming you are correct and this is the issue, then > reading 128 bits (16 bytes) from /dev/random should "exhaust the > supply" and...

...ev/random returns one byte for one byte of entropy received, but > > it has a lower limit of 64 bits > > > > - getrandom behaves like /dev/urandom (i.e. nonblocking) except > > during boot where it waits until the RNG has collected 128 bits > > before operating like a DRNG that is seeded once in a while when > > entropy comes in. > > > > > > Ciao > > Stephan > > I don't follow. Assuming you are correct and this is the issue, then > reading 128 bits (16 bytes) from /dev/random should "exhaust the > supply" and...

...free(vec.plaintext); kfree(vec.digest); crypto_free_shash(generic_tfm); - kzfree(generic_desc); + kfree_sensitive(generic_desc); return err; } #else /* !CONFIG_CRYPTO_MANAGER_EXTRA_TESTS */ @@ -3665,7 +3665,7 @@ static int drbg_cavs_test(const struct drbg_testvec *test, int pr, if (IS_ERR(drng)) { printk(KERN_ERR "alg: drbg: could not allocate DRNG handle for " "%s\n", driver); - kzfree(buf); + kfree_sensitive(buf); return -ENOMEM; } @@ -3712,7 +3712,7 @@ static int drbg_cavs_test(const struct drbg_testvec *test, int pr, outbuf: crypto_free_...

...free(vec.plaintext); kfree(vec.digest); crypto_free_shash(generic_tfm); - kzfree(generic_desc); + kfree_sensitive(generic_desc); return err; } #else /* !CONFIG_CRYPTO_MANAGER_EXTRA_TESTS */ @@ -3665,7 +3665,7 @@ static int drbg_cavs_test(const struct drbg_testvec *test, int pr, if (IS_ERR(drng)) { printk(KERN_ERR "alg: drbg: could not allocate DRNG handle for " "%s\n", driver); - kzfree(buf); + kfree_sensitive(buf); return -ENOMEM; } @@ -3712,7 +3712,7 @@ static int drbg_cavs_test(const struct drbg_testvec *test, int pr, outbuf: crypto_free_...

...free(vec.plaintext); kfree(vec.digest); crypto_free_shash(generic_tfm); - kzfree(generic_desc); + kfree_sensitive(generic_desc); return err; } #else /* !CONFIG_CRYPTO_MANAGER_EXTRA_TESTS */ @@ -3665,7 +3665,7 @@ static int drbg_cavs_test(const struct drbg_testvec *test, int pr, if (IS_ERR(drng)) { printk(KERN_ERR "alg: drbg: could not allocate DRNG handle for " "%s\n", driver); - kzfree(buf); + kfree_sensitive(buf); return -ENOMEM; } @@ -3712,7 +3712,7 @@ static int drbg_cavs_test(const struct drbg_testvec *test, int pr, outbuf: crypto_free_...

v5: - Break the btrfs patch out as a separate patch to be processed independently. - Update the commit log of patch 1 to make it less scary. - Add a kzfree backward compatibility macro in patch 2. v4: - Break out the memzero_explicit() change as suggested by Dan Carpenter so that it can be backported to stable. - Drop the "crypto: Remove unnecessary

v4: - Break out the memzero_explicit() change as suggested by Dan Carpenter so that it can be backported to stable. - Drop the "crypto: Remove unnecessary memzero_explicit()" patch for now as there can be a bit more discussion on what is best. It will be introduced as a separate patch later on after this one is merged. This patchset makes a global rename of the kzfree()

v4: - Break out the memzero_explicit() change as suggested by Dan Carpenter so that it can be backported to stable. - Drop the "crypto: Remove unnecessary memzero_explicit()" patch for now as there can be a bit more discussion on what is best. It will be introduced as a separate patch later on after this one is merged. This patchset makes a global rename of the kzfree()

This patchset makes a global rename of the kzfree() to kfree_sensitive() to highlight the fact buffer clearing is only needed if the data objects contain sensitive information like encrpytion key. The fact that kzfree() uses memset() to do the clearing isn't totally safe either as compiler may compile out the clearing in their optimizer. Instead, the new kfree_sensitive() uses