search for: 2048bit

...DSA identity keys are only used with protocol 2, that is what I've tested so far. I have NOT tested OpenSSH with large RSA1 or RSA keys. Furthermore, this bug may also occur with host keys, but again I have not tested. Lastly, I agree that there is limited amount of extra security afforded by a 2048bit key, but that isn't the point here. Note that I am NOT subscribed to this list. Therefore, I'd like to have replies and any eventual resolution CC'ed to me please. Thanks Eddie <epl at unimelb.edu.au>

Hello, from my understanding, using 1024bit DH parameters results in a not sufficiently secure key exchange for DH(E). Therefore I think it would be advisable to have parameters of at least 2048bit . In fact, I would see a great benefit in chosing parameter length arbitrarily. I also do not see the benefit of parameter regeneration. What were the design goals here? Thanks, J?rg L?bbert

Hi, I'm migrating from Courier to Dovecot and would like to keep the original namespace and add two new ones on the new server. There's only one namespace in Courier which is "INBOX." . The seperator is "." In the new server I would like to have 3 namespaces (private, public, shared) and use "/" as separator. Is it possible to keep "INBOX." for

On Sat, Jul 9, 2016 at 10:30 AM, Ben Lindstrom <mouring at eviladmin.org> wrote: > You'd do this by either moving the authorized_keys to another a root owned > location using "AuthorizedKeysFile" (e.g. AuthorizedKeysFile > /etc/ssh/keys/authorized_keys.%u). Or you use "AuthorizedKeysCommand" and > put the keys into a "database" to reference

...lassid 1:20 htb rate 10kbit ceil 256kbit quantum 1514 $tc class add dev $i parent 1:1 classid 1:30 htb rate 10kbit ceil 512kbit quantum 1514 $tc class add dev $i parent 1:1 classid 1:40 htb rate 10kbit ceil 1024bit quantum 1514 $tc class add dev $i parent 1:1 classid 1:50 htb rate 10kbit ceil 2048bit quantum 1514 $tc class add dev $i parent 1:1 classid 1:60 htb rate 10kbit ceil 256kbit quantum 1514 # USED FOR HTTP/IRC $tc class add dev $i parent 1:1 classid 1:70 htb rate 10kbit ceil 128kbit quantum 1514 # USED FOR EMAIL (SMTP/POP3) $tc qdisc add dev $i parent 1:10 handle 10: sfq perturb 10...

...: 4.2p1 Platform: Sparc OS/Version: Solaris Status: NEW Severity: normal Priority: P2 Component: ssh-keygen AssignedTo: bitbucket at mindrot.org ReportedBy: rgconner at pacbell.net ssh-keygen's appears to be generating 2048bit dsa keys, contrary to the documentation which says dsa keys must be 1024. Can be overridden with -b 1024 to generate a valid key. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.

...ouple PINs, some mail certs and some keypairs added. Seems it works as expected *IF* the only (or first) on-card keypair is the one to be used for SSH. If it's after other keys/certs there's no way (I know of) to avoid testing all the preceeding keys (that's really heavy: I have had 58 2048bit RSA keypairs on a single MyEID card during test phase!). The result is that I always get a "Too many authentication failures" error. Maybe a semantic extension for '-i' parameter, to use the given key ID? Please, don't tell me "use a card only for SSH"... That woul...

Hello, after switching from version 2.2.7 to 2.2.7 I miss the loglines which say: ssl-params: Generating SSL parameters ssl-params: SSL parameters regeneration completed The configuration has not been changed and reads: | # 2.2.7: /usr/local/dovecot/etc/dovecot/dovecot.conf | # OS: Linux 2.6.35.14-106.fc14.i686.PAE i686 Fedora release 14 (Laughlin) ext3 | auth_mechanisms = plain login |

Please tell me whether the following implementation is correct..... My target supports 64 bit mask means immediate(0-2^63) I have implemented it but i dont know whether its correct or not. Please see the changes below that i have made in x86isellowering.cpp static SDValue lower2048BitVectorShuffle(const SDLoc &DL, ArrayRef<int> Mask, MVT VT, SDValue V1, SDValue V2, const SmallBitVector &Zeroable, const X86Subtarget &Subtarget,...

Alice Wonder wrote: > On 04/27/2016 01:21 AM, Brandon Vincent wrote: >> On Wed, Apr 27, 2016 at 1:10 AM, Rob Kampen <rkampen at kampensonline.com> wrote: >>> Sounds good, but how many domain MX servers have set up these >>> fingerprint keys - 1%, maybe 2%, so how do you code for that? I guess I'm thinking >>> it uses it if available. So even if you do

...ener imap { address = * } inet_listener imaps { address = * } } service managesieve-login { inet_listener sieve { address = * port = 4190 } } ssl = required ssl_cert = </etc/pki/dovecot/certs/mail.ela-soft.com.crt ssl_key = </etc/pki/dovecot/private/mail.ela-soft.com.2048bit.nopp.key userdb { args = /etc/dovecot/dovecot-ldap.conf driver = ldap } protocol lmtp { mail_plugins = " sieve" } Any ideas? Greetings Andreas

...ener imap { address = * } inet_listener imaps { address = * } } service managesieve-login { inet_listener sieve { address = * port = 4190 } } ssl = required ssl_cert = </etc/pki/dovecot/certs/mail.ela-soft.com.crt ssl_key = </etc/pki/dovecot/private/mail.ela-soft.com.2048bit.nopp.key userdb { args = /etc/dovecot/dovecot-ldap.conf driver = ldap } protocol lda { mail_plugins = " quota acl sieve" } protocol imap { mail_plugins = " quota acl imap_quota imap_acl" } protocol lmtp { mail_plugins = " quota acl sieve" }

...e.g. if the RFC would mandate it for a conforming implementation). If a user/admin removes it from his KEX algo preference list, then he probably does so by intention and thus this shouldn't be silently reverted again by ssh/sshd. Further, according to e.g. the ECRYPT II recommendations,... a 2048bit group as in group14 is only suggested for something between "legacy standard level" and "Medium term protection",... which may not be enough for some people. Since its typically those people who try to disable the algo by removing it from their preference lists, that fallback be...

...e.g. if the RFC would mandate it for a conforming implementation). If a user/admin removes it from his KEX algo preference list, then he probably does so by intention and thus this shouldn't be silently reverted again by ssh/sshd. Further, according to e.g. the ECRYPT II recommendations,... a 2048bit group as in group14 is only suggested for something between "legacy standard level" and "Medium term protection",... which may not be enough for some people. Since its typically those people who try to disable the algo by removing it from their preference lists, that fallback be...